On Wed, Mar 11, 2009 at 1:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Greg Stark <stark@enterprisedb.com> writes:
>> On Wed, Mar 11, 2009 at 12:38 PM, Tom Lane <tgl@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
