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



Tue, 02 Dec 2003 11:49:54 -0800
Joe Conway <mail@joeconway.com>
request for feedback - read-only GUC variables, pg_settings changes
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 ...

Tue, 2 Dec 2003 19:43:01 -0400 (AST)
"Marc G. Fournier" <scrappy@postgresql.org>
Re: request for feedback - read-only GUC variables,
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, Pennsylvania 19073

Thu, 4 Dec 2003 06:53:40 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: request for feedback - read-only GUC variables, pg_settings
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, Pennsylvania 19073

Thu, 4 Dec 2003 07:03:23 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: request for feedback - read-only GUC variables,
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"

Thu, 4 Dec 2003 09:21:37 -0300
Alvaro Herrera <alvherre@dcc.uchile.cl>
Re: request for feedback - read-only GUC variables, pg_settings
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


Thu, 04 Dec 2003 06:57:37 -0800
Joe Conway <mail@joeconway.com>
Re: request for feedback - read-only GUC variables,
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


04 Dec 2003 11:39:50 -0500
Greg Stark <gsstark@mit.edu>
Re: request for feedback - read-only GUC variables, pg_settings
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, Pennsylvania 19073

Sat, 6 Dec 2003 10:31:36 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: request for feedback - read-only GUC variables, pg_settings