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
---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
