Skip site navigation (1) Skip section navigation (2)

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

From: Neil Conway <neilc(at)samurai(dot)com>
To: "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>
Cc: Sean Chittenden <sean(at)chittenden(dot)org>,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Bumping block size to 16K on FreeBSD...
Date: 2003-08-29 03:25:49
Message-ID: 20030829032549.GK63737@home.samurai.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, Aug 29, 2003 at 12:06:59AM -0300, Marc G. Fournier wrote:
> "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 ...

No, it's a perfectly valid reason for not doing this (in the present,
half-baked form that has been presented). PostgreSQL is at the moment
fairly simple to configure. Adding a significant amount of complexity
to the configuration / tuning process and making a given configuration
non-portable between different platforms and different compiles of
PostgreSQL is something I'd like to avoid, if possible.

And I think it's possible to avoid it, it's just that the original
patch makes no attempt to do so. For example, why does
shared_buffers need to be specified in disk pages, anyway? ISTM it
could just as easily be specified in bytes, and PostgreSQL could
internally round up/down to the nearest multiple of the BLCKSZ that
this instance of PostgreSQL happened to be compiled with.

> 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 ...

Uh, yeah -- I was talking about that as well. I said "it needs to be
completely transparent to the user, from a functionality perspective".
If changing the BLCKSZ makes things faster or slower, then fine; if it
changes the meaning of various random configuration parameters, makes
certain schemas work or not work, and makes other changes to postgres
functionality, then it's not fine.

-Neil


In response to

pgsql-hackers by date

Next:From: Curt SampsonDate: 2003-08-29 03:29:14
Subject: Re: Bumping block size to 16K on FreeBSD...
Previous:From: Tom LaneDate: 2003-08-29 03:23:13
Subject: Re: FE/BE Protocol - Specific version

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group