Обсуждение: request for feedback - read-only GUC variables, pg_settings changes
We (mostly Bruce, Tom, Peter, and I) have been having a discussion on the PATCHES list regarding some new functionality related to read-only GUC variables. The net result is pasted at the bottom of this post. Here is a link to the discussion: http://archives.postgresql.org/pgsql-patches/2003-11/msg00363.php In short, 5 new read-only GUC variables are created allowing the value of certain compile-time settings to be queried. Also the pg_settings system view has been expanded to include category, short_desc, and extra_desc (corresponding to group, short_desc, and long_desc in the generic guc structure). The 5 GUC variables are: block_size - int Shows size of a disk block integer_datetimes - bool Datetimes are integer based max_function_args - int Shows the maximum number of function arguments max_identifier_length - int Shows the maximum identifier length max_index_keys - int Shows the maximum number of index keys The main open question at this point is the name for the "block_size" variable. Peter favors "block_size", Bruce favors "page_size", Tom hasn't taken a position on that specific issue. Does anyone have and opinion on the variable name, or any general comments before I commit this? Thanks, Joe regression=# select * from pg_settings where category like 'Compile%'; -[ RECORD 1 ]---------------------------------------------- name | block_size setting | 8192 category | Compiled-in Options short_desc | Shows size of a disk block extra_desc | context | internal vartype | integer source | default min_val | 8192 max_val | 8192 -[ RECORD 2 ]---------------------------------------------- name | integer_datetimes setting | on category | Compiled-in Options short_desc | Datetimes are integer based extra_desc | context | internal vartype | bool source | default min_val | max_val | -[ RECORD 3 ]---------------------------------------------- name | max_function_args setting | 32 category | Compiled-in Options short_desc | Shows the maximum number of function arguments extra_desc | context | internal vartype | integer source | default min_val | 32 max_val | 32 -[ RECORD 4 ]---------------------------------------------- name | max_identifier_length setting | 63 category | Compiled-in Options short_desc | Shows the maximum identifier length extra_desc | context | internal vartype | integer source | default min_val | 63 max_val | 63 -[ RECORD 5 ]---------------------------------------------- name | max_index_keys setting | 32 category | Compiled-in Options short_desc | Shows the maximum number of index keys extra_desc | context | internal vartype | integer source | default min_val | 32 max_val | 32
On Tue, 2 Dec 2003, Joe Conway wrote: > We (mostly Bruce, Tom, Peter, and I) have been having a discussion on > the PATCHES list regarding some new functionality related to read-only > GUC variables. The net result is pasted at the bottom of this post. Here > is a link to the discussion: > http://archives.postgresql.org/pgsql-patches/2003-11/msg00363.php > > In short, 5 new read-only GUC variables are created allowing the value > of certain compile-time settings to be queried. Also the pg_settings > system view has been expanded to include category, short_desc, and > extra_desc (corresponding to group, short_desc, and long_desc in the > generic guc structure). The 5 GUC variables are: > > block_size - int > Shows size of a disk block > integer_datetimes - bool > Datetimes are integer based > max_function_args - int > Shows the maximum number of function arguments > max_identifier_length - int > Shows the maximum identifier length > max_index_keys - int > Shows the maximum number of index keys > > The main open question at this point is the name for the "block_size" > variable. Peter favors "block_size", Bruce favors "page_size", Tom > hasn't taken a position on that specific issue. Does anyone have and > opinion on the variable name, or any general comments before I commit this? PAGE_SIZE generally refers to memory allocations, no? I'd go with block_size ...
Joe Conway wrote: > We (mostly Bruce, Tom, Peter, and I) have been having a discussion on > the PATCHES list regarding some new functionality related to read-only > GUC variables. The net result is pasted at the bottom of this post. Here > is a link to the discussion: > http://archives.postgresql.org/pgsql-patches/2003-11/msg00363.php > > In short, 5 new read-only GUC variables are created allowing the value > of certain compile-time settings to be queried. Also the pg_settings > system view has been expanded to include category, short_desc, and > extra_desc (corresponding to group, short_desc, and long_desc in the > generic guc structure). The 5 GUC variables are: > > block_size - int > Shows size of a disk block > The main open question at this point is the name for the "block_size" > variable. Peter favors "block_size", Bruce favors "page_size", Tom > hasn't taken a position on that specific issue. Does anyone have and > opinion on the variable name, or any general comments before I commit this? I hate to reply to this because I have already cast my vote, but "block_size" does not report the size of a disk block. It reports the size of a PostgreSQL block/page. Disk blocks are almost always 512 bytes in size. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Marc G. Fournier wrote: > > block_size - int > > Shows size of a disk block > > integer_datetimes - bool > > Datetimes are integer based > > max_function_args - int > > Shows the maximum number of function arguments > > max_identifier_length - int > > Shows the maximum identifier length > > max_index_keys - int > > Shows the maximum number of index keys > > > > The main open question at this point is the name for the "block_size" > > variable. Peter favors "block_size", Bruce favors "page_size", Tom > > hasn't taken a position on that specific issue. Does anyone have and > > opinion on the variable name, or any general comments before I commit this? > > PAGE_SIZE generally refers to memory allocations, no? > > I'd go with block_size ... True, page size usually references virtual memory pages, so it is related to virtual memory mapping. Block size is much more related to on-disk storage, true. The only reason I was leaning toward page is that it is possible to confuse disk block (512 bytes) with a PostgreSQL block (8k), but maybe that is not relivant. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Thu, Dec 04, 2003 at 06:53:40AM -0500, Bruce Momjian wrote: > Joe Conway wrote: > > The main open question at this point is the name for the "block_size" > > variable. Peter favors "block_size", Bruce favors "page_size", Tom > > hasn't taken a position on that specific issue. Does anyone have and > > opinion on the variable name, or any general comments before I commit this? > > I hate to reply to this because I have already cast my vote, but > "block_size" does not report the size of a disk block. It reports the > size of a PostgreSQL block/page. Disk blocks are almost always 512 > bytes in size. pg_block_size ? -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) "God is real, unless declared as int"
Bruce Momjian wrote: > Marc G. Fournier wrote: >>I'd go with block_size ... > > True, page size usually references virtual memory pages, so it is > related to virtual memory mapping. Block size is much more related to > on-disk storage, true. The only reason I was leaning toward page is > that it is possible to confuse disk block (512 bytes) with a PostgreSQL > block (8k), but maybe that is not relivant. I committed this yesterday as block_size because that had the majority support. Of course it's not too late to change it, but as Tom mentioned, we want to settle on something relatively quickly and then not mess with it afterwards. As another data point in the discussion, pg_controldata gives this: # pg_controldata pg_control version number: 72 Catalog version number: 200312031 Database cluster state: in production pg_control last modified: Wed Dec 3 12:06:35 2003 Current log file ID: 0 Next log file segment: 3 Latest checkpoint location: 0/27D5EEC Prior checkpoint location: 0/9BA8A0 Latest checkpoint's REDO location: 0/27D5EEC Latest checkpoint's UNDO location: 0/0 Latest checkpoint's StartUpID: 14 Latest checkpoint's NextXID: 6376 Latest checkpoint's NextOID: 156406 Time of latest checkpoint: Wed Dec 3 12:06:31 2003 Database block size: 8192 Blocks per segment of large relation: 131072 Maximum length of identifiers: 64 Maximum number of function arguments: 32 Date/time type storage: 64-bit integers Maximum length of locale name: 128 LC_COLLATE: C LC_CTYPE: C Note that pg_controldata also uses "block size", so I'm still inclined to stick with that. Joe
Bruce Momjian <pgman@candle.pha.pa.us> writes: > I hate to reply to this because I have already cast my vote, but > "block_size" does not report the size of a disk block. It reports the > size of a PostgreSQL block/page. Disk blocks are almost always 512 > bytes in size. Perhaps then neither "block" nor "page" is best. Perhaps it should be "buffer_size" or something like that? -- greg
Greg Stark wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > I hate to reply to this because I have already cast my vote, but > > "block_size" does not report the size of a disk block. It reports the > > size of a PostgreSQL block/page. Disk blocks are almost always 512 > > bytes in size. > > Perhaps then neither "block" nor "page" is best. Perhaps it should be > "buffer_size" or something like that? It is really the storage block size, and that is manifest in the buffer size and disk block size used. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073