Re: [PATCH] Cleanup of GUC units code - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [PATCH] Cleanup of GUC units code
Date
Msg-id 603c8f070809091233i72e69f21yad2b473234dd217f@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Cleanup of GUC units code  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: [PATCH] Cleanup of GUC units code  (Greg Smith <gsmith@gregsmith.com>)
List pgsql-hackers
> This would have definitional problems of its own, however.  If you interpret
> K, M, and G strictly as unit-less multipliers, then
>
> SET shared_buffers = 2 G

I don't think it would be a good idea to make them unit-less, for
exactly the reasons you mention.

> We could possibly settle some of these arguments if we could redefine all
> memory parameters to use one byte as base unit, and then allow some
> ambiguity and unit omission from there.  But that would probably cause much
> havoc, so we are stuck with a certain degree of inconsistency anyhow.

A good start might be to always OUTPUT memory parameters using the
same base unit.

portal=# show shared_buffers;shared_buffers
----------------24MB
(1 row)

portal=# show temp_buffers;temp_buffers
--------------1024
(1 row)

Kilobytes seems like the most reasonable choice, because we definitely
have variables where you would want to set a value less than 1
megabyte, and I doubt we have (or will ever need) any where we the
granularity is finer than than 1 kilobyte.

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.

...Robert


pgsql-hackers by date:

Previous
From: Devrim GÜNDÜZ
Date:
Subject: Keeping creation time of objects
Next
From: Tom Lane
Date:
Subject: Re: Keeping creation time of objects