From: | Michael Glaesemann <grzm(at)seespotcode(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Martijn van Oosterhout <kleptog(at)svana(dot)org>, "Bort, Paul" <pbort(at)tmwsystems(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Neil Conway <neilc(at)samurai(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: GUC with units, details |
Date: | 2006-07-27 07:49:31 |
Message-ID: | 61811CA7-4DCE-406B-845D-05BFF42B39FE@seespotcode.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Jul 27, 2006, at 14:03 , Tom Lane wrote:
> What we're talking about here is ways to specify the intended
> usage with other units (eg "I want N megabytes of shared buffers") but
> that's not going to magically let you allocate half a shared buffer.
> Peter's not said exactly how he plans to deal with this, but I suppose
> it'll round off one way or the other ...
Thanks, Tom. That make sense to me, and helps me better understand
the motivation for the patch. I was a bit thrown off by comments such
as this one by Peter [1]:
> I'd imagine that one of the first things someone will want to try is
> something like SET work_mem TO '10MB', which will fail or misbehave
> because 10000000 bytes do not divide up into chunks of 1024 bytes.
> Who
> wants to explain to users that they have to write '10MiB'?
Granted, the K=1024/1000 issue will affect how 10MB is interpreted,
but if it's rounded to the nearest whole page or buffer, it shouldn't
"fail or misbehave", I'd think.
Michael Glaesemann
grzm seespotcode net
[1](http://archives.postgresql.org/pgsql-hackers/2006-07/msg01249.php)
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2006-07-27 08:32:22 | Re: GUC with units, details |
Previous Message | Tom Lane | 2006-07-27 06:50:35 | Re: On-disk bitmap index patch |