Re: GUC with units, details

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)

In response to

Browse pgsql-hackers by date

  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