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