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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Curt Sampson | 2003-08-29 03:29:14 | Re: Bumping block size to 16K on FreeBSD... |
Previous Message | Tom Lane | 2003-08-29 03:23:13 | Re: FE/BE Protocol - Specific version |