RE: 8192 BLCKSZ ?]

At 10:52 AM 12/2/00 +1100, Andrew Snow wrote:
>
>
>> The cost difference between 32K vs 8K disk reads/writes are so small
>> these days when compared with overall cost of the disk operation itself,
>> that you can even measure it, well below 1%. Remember seek times
>> advertised on disks are an average.
>
>It has been said how small the difference is - therefore in my opinion it
>should remain at 8KB to maintain best average performance with all existing
>platforms.

With versions <= PG 7.0, the motivation that's been stated isn't performance
based as much as an option to let you stick relatively big chunks of text
(~40k-ish+ for lzText) in a single row without resorting to classic PG's
ugly LOB interface or something almost as ugly as the built-in LOB handler
I did for AOLserver many months ago. The performance arguments have mostly
been of the form "it won't really cost you much and you can use rows that
are so much longer ..."

I think there's been recognition that 8KB is a reasonable default, along with
lamenting (at least on my part) that the fact that this is just a DEFAULT hasn't
been well-communicated, leading many casual surveyors of DB alternatives to
believe that it is truly a hard-wired limitation. Causing PG's reputation to
suffer as a result. One could argue that PG"s reputation would've been
enhanced in past years if a 32KB block size limit rather than 8KB block size
default had been emphasized.

But you wouldn't have to change the DEFAULT in order to make this claim! It
would've been just a matter of emphasizing the limit rather than the default.

PG 7.1 will pretty much end any confusion. The segmented approach used by
TOAST should work well (the AOLserver LOB handler I wrote months ago works
well in the OpenACS context, and uses a very similar segmentation scheme, so
I expect TOAST to work even better). Users will still be able change to
larger blocksizes (perhaps a wise thing to do if a large percentage of their
data won't fit into a single PG block). Users using the default will
be able to store rows of *awesome* length, efficiently.

- Don Baccus, Portland OR <dhogaza(at)pacifier(dot)com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.