| From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Greg Smith <gsmith(at)gregsmith(dot)com>, 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-11 11:28:45 |
| Message-ID: | 48C900ED.3010902@gmx.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
>
> Not for me it doesn't.
>
> portal=# show temp_buffers;
> temp_buffers
> --------------
> 1024
> (1 row)
>
> portal=# set temp_buffers = '16MB';
> SET
> portal=# show temp_buffers;
> temp_buffers
> --------------
> 2048
> (1 row)
temp_buffers is actually special-cased in the code because
/*
* We show the GUC var until local buffers have been initialized, and
* NLocBuffer afterwards.
*/
It is not clear to me right now why that is a good idea. But it is only
this one paramter.
The actual logic that SHOW uses in the general case is to reformat the
value with the largest unit that allows for an integer value to be
presented. So this is neither your nor Greg's idea, but I think it
gives useful behavior in practice.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2008-09-11 11:42:05 | Re: Postgresql coding conventions |
| Previous Message | Gregory Stark | 2008-09-11 11:18:18 | Re: Transaction Snapshots and Hot Standby |