Re: [PATCH] Cleanup of GUC units code
От | Greg Smith |
---|---|
Тема | Re: [PATCH] Cleanup of GUC units code |
Дата | |
Msg-id | Pine.GSO.4.64.0809091834350.16003@westnet.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Cleanup of GUC units code ("Robert Haas" <robertmhaas@gmail.com>) |
Ответы |
Re: [PATCH] Cleanup of GUC units code
(Tom Lane <tgl@sss.pgh.pa.us>)
Re: [PATCH] Cleanup of GUC units code ("Robert Haas" <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
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 gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
В списке pgsql-hackers по дате отправления: