On Tue, 9 Sep 2008, Robert Haas wrote:
A good start might be to always OUTPUT memory parameters using the
same base unit.
SHOW gives output that matches what you input. If you want to see things
with consistant units, look at pg_settings:
# select name,unit,setting,current_setting(name) from pg_settings where
name='shared_buffers' or name='temp_buffers';
name | unit | setting | current_setting
----------------+------+---------+-----------------
shared_buffers | 8kB | 131072 | 1GB
temp_buffers | 8kB | 1024 | 1024
Beyond that, how about moving in the direction of deprecating
unit-less settings altogether? In other words, if you want 1024
shared buffers, you should be saying 8192kB or 8MB rather than 1024.
We could issue a WARNING for 8.4 and eventually move to rejecting that
syntax altogether. That gets everything into the same base unit
without ever change the semantics of any particular value.
Deprecating setting the value directly in its base unit, so that all the
memory parameters are specified as a number of bytes, would sidestep a lot
of the issues people complain about. What I would like to see (but don't
have nearly enough time to argue in support of considering the resistance
to change here) is that this syntax:
shared_buffers=1024
Would assume the user meant 1024 *bytes*, with the server silently
rounding that up to the nearest 8k block. Then the whole issue of "do
they mean bits or bytes?" goes away, because no one would ever have to
include the "B". That paves the way for making it easy to support
case-insensitive values without pedantic confusion. As I see it these
should all give you the same thing:
shared_buffers=16777216
shared_buffers=16384k
shared_buffers=16384K
shared_buffers=16M
shared_buffers=16m
Because that's what would make life easiest for those configuring the
software.
Since this suggestion will inevitably lead to cries of befowled backward
compatibility, what I've been doing instead of participating in this
thread is working on a tool that will make it easy to convert old
postgresql.conf files to support a new version. Then the tool can convert
all the places someone uses the old syntax into the new.
--
* Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
