Re: Bumping block size to 16K on FreeBSD...

On Thu, 28 Aug 2003, Neil Conway wrote:

> On Thu, Aug 28, 2003 at 01:00:44PM -0700, Sean Chittenden wrote:
> > Other than you feeling uneasy about the possibility of uncovering bugs
> > because this hasn't been widely done like this before, do you have any
> > other concerns, or do you think the possibility of finding bugs very
> > likely?
>
> In case Tom didn't make this clear, I'm strongly opposed to making
> this change without doing the necessary (non-FreeBSD-specific) legwork.
> The bottom-line is that if we're going to be changing the block size
> on a regular basis, it needs to be completely transparent to the user,
> from a functionality perspective. That's currently not the case:
> changing the BLCKSZ changes the meaning of shared_buffers and
> effective_cache_size, for example, so tuning documents written for
> other operating systems won't apply as easily to PostgreSQL on
> FreeBSD. Until the user-visible effects of BLCKSZ have been ironed
> over[1], I definately think you shouldn't include the patch in the
> FreeBSD port.

"tuning documents" is *not* a valid reason for not doing this ... that's
like saying "we can make it faster on some operating systems, but because
we're going to have to modify the tuning documents, we're not going to do
it" ... wait, that is exactly what you are saying ...

Now, Tom made one point in his original that *was* valid ... a table
definition made under a 16k BLCKSZ db will not necessarily work under an
8k compiled server .. the example that he made to me was that a table of
float8 under a 16k server could have N fields, but if you tried to
dump/import that table into an 8k BLCKSZ one with that max # of fields, it
would fail ... that is a *serious* concern against doing this ...

Now, here's a question for someone running a non-FreeBSD OS ... if we were
to jump the BLCKSZ to 16k, would it cause a degradation in performance, or
would it make no difference to them?  Would they see an 8% reduction in
performance?

The thing is ... there has been presented a strong, valid reason for
moving to 16k (at least under FreeBSD) ... and there has been a valid
reason for not making it "easily configurable" ... but, are there any
strong reasons not to just move to 16k across the board?