Skip site navigation (1) Skip section navigation (2)

Re: GUC with units, details

From: "Bort, Paul" <pbort(at)tmwsystems(dot)com>
To: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: GUC with units, details
Date: 2006-07-26 21:29:38
Message-ID: DB106B1B5B8F734B8FF3E155A3A556C202D4FD89@clemail1.tmwsystems.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Martijn van Oosterhout wrote:
> > 
> > How about this:
> > 
> > INFO: Your setting was converted to IEC standard binary 
> units. Use KiB,
> > MiB, and GiB to avoid this warning. 
> 
> That's silly. If you're going to treat KB as 1024 bytes anyway,
> complaining about it is just being pedantic.

But after a version or two with warnings, we have grounds to make it an
error. I'd rather just go with the standard from day 1 and reject
decimal units where they don't make sense, but that seems unlikely.

> 
> The thing is, most memory sizes in postgres need to be some 
> multiple of
> a page size. You can't have a shared buffers of exactly 100000 bytes,
> while 102400 bytes is possible. When someone has a GB of memory, they
> really mean a GiB, but no-one bothers to correct them.

And hard drives are just the opposite: a 250GB drive does not have
268,435,456,000 bytes of unformatted space.

> 
> Is there anywhere in postgres where using K=1000 would be 
> significantly
> clearer than K=1024?

If the unit for a setting is pages, then a value of '1K' could cause
some confusion as to whether that's 1,000 or 1,024 pages.


> 
> Have a nice day,
> -- 
> Martijn van Oosterhout   <kleptog(at)svana(dot)org>   
> http://svana.org/kleptog/
> > From each according to his ability. To each according to 
> his ability to litigate.
> 

In response to

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2006-07-26 21:35:42
Subject: Re: [HACKERS] [PATCH] Provide 8-byte transaction IDs to user level
Previous:From: Hannu KrosingDate: 2006-07-26 21:29:17
Subject: Re: [HACKERS] Resurrecting per-page cleaner for btree

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group