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