Re: [PATCH] Cleanup of GUC units code
От | Robert Haas |
---|---|
Тема | Re: [PATCH] Cleanup of GUC units code |
Дата | |
Msg-id | 603c8f070809091233i72e69f21yad2b473234dd217f@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Cleanup of GUC units code (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: [PATCH] Cleanup of GUC units code
|
Список | 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 по дате отправления: