Re: [PATCH] Cleanup of GUC units code

From: "Robert Haas" <robertmhaas(at)gmail(dot)com>
To: "Peter Eisentraut" <peter_e(at)gmx(dot)net>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Greg Stark" <stark(at)enterprisedb(dot)com>, "Simon Riggs" <simon(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>, "Marko Kreen" <markokr(at)gmail(dot)com>, "Asko Oja" <ascoja(at)gmail(dot)com>
Subject: Re: [PATCH] Cleanup of GUC units code
Date: 2008-09-09 19:33:37
Message-ID: 603c8f070809091233i72e69f21yad2b473234dd217f@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-09-09 19:36:19 Re: Keeping creation time of objects
Previous Message Devrim GÜNDÜZ 2008-09-09 19:20:00 Keeping creation time of objects