On Wed, Mar 11, 2009 at 1:13 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Greg Stark <st...@enterprisedb.com> writes: >> On Wed, Mar 11, 2009 at 12:38 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>>> And there seems nothing diffcult to implement this. Is that true? >>> >>> No. > >> Eh? There's nothing difficult in implementing it. > >> But there are a lot of other constants dependant on this value which >> are currently compile-time constants. > > Exactly, and we rely on them being constants, eg to size arrays. > > There's no free lunch, and in this particular case there is no evidence > whatsoever that it'd be worth the trouble to support run-time-variable > BLCKSZ.
The main advantage would be for circumstances such as the Windows installer where users are installing precompiled binaries. They don't get an opportunity to choose the block size at all. (Similarly for users of binary-only commercial products such as EDB's but the Windows installer makes a pretty good argument on its own). I think the question hinges on whether there's any real benefit to block size at all. The current situation is that the facility is available for people to test and demonstrate that it's helpful. But there are so many variables -- filesystem type, filesystem block size, raid array stripe size, OS readahead, database work-load -- that nobody's done that kind of testing extensively enough to separate the effects of block size from other effects. If we had a solid use case for adjusting block size at all I think we would also need to make it adjustable at initdb time for those binary-only installs. Until we do leaving the compile-time configuration in for people to experiment with is sufficient. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
