Tom Lane wrote:
If that actually worked, it'd be one thing, but it doesn't work and
isn't going to do so in 8.2. So I think people will indeed be trying
to use setting || unit for display purposes. In any case 8kB isn't
a valid unit.
I thought we set SHOW ALL aside for display purposes and
Ühel kenal päeval, N, 2006-07-27 kell 01:03, kirjutas Tom Lane:
Michael Glaesemann [EMAIL PROTECTED] writes:
I've seen this mentioned a couple of times. I'm not nearly as
familiar with these settings as I should be, but it seems to me that
if the memory size *does* need to be a integral
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
If that actually worked, it'd be one thing, but it doesn't work and
isn't going to do so in 8.2. So I think people will indeed be trying
to use setting || unit for display purposes. In any case 8kB isn't
a valid unit.
I thought we
On Fri, Jul 28, 2006 at 01:03:00AM +0200, Peter Eisentraut wrote:
Accepting page (or block?) as a unit might be a reasonable
You hit on something that's always irked me a bit... we tend to toss out
'page' and 'block' (and sometimes even 'buffer') randomly when referring
to different things that
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
Tom Lane wrote:
It is. For instance shared_buffers is configured as the number of
buffers. 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.
Bort, Paul wrote:
I still think it would be a good idea to use the standard, and that
this is an opportunity to do so.
I have committed it using the 1024 multiplier, but if you want to
propose changing all uses of kB, MB, and GB in PostgreSQL to the other
system, now would be the time to do
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
Peter's not said exactly how he plans to deal with
this, but I suppose it'll round off one way or the other ...
It'll get truncated by integer division. I wouldn't mind if someone
proposed a patch to create a warning or error in
Peter Eisentraut wrote:
I have committed it using the 1024 multiplier, but if you want to
propose changing all uses of kB, MB, and GB in PostgreSQL to
the other
system, now would be the time to do it.
I think it would be a good idea. I know I don't have time to do it for
8.2.
I get
Bort, Paul wrote:
Peter Eisentraut wrote:
I have committed it using the 1024 multiplier, but if you want to
propose changing all uses of kB, MB, and GB in PostgreSQL to
the other
system, now would be the time to do it.
I think it would be a good idea. I know I don't have time
On Jul 27, 2006, at 9:16 AM, Bort, Paul wrote:
Peter Eisentraut wrote:
I have committed it using the 1024 multiplier, but if you want to
propose changing all uses of kB, MB, and GB in PostgreSQL to
the other
system, now would be the time to do it.
I think it would be a good idea. I know I
[snip]
Forcing people to use a specific casing scheme is just going to lead
to confusion and user frustration. If there's not a very solid
I guess nobody will force people to use the units at all.
*functional* argument for it, we shouldn't do it. Wanting to enforce
a convention that
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
Peter's not said exactly how he plans to deal with
this, but I suppose it'll round off one way or the other ...
It'll get truncated by integer division. I wouldn't mind if someone
proposed a patch to create a
Jim Nasby wrote:
The truth is, virtually no one, even highly technical people, ever
picks nits between kB vs KiB vs KB.
The question isn't so much whether to allow KiB and such -- that would
obviously be trivial. The question is whether we want to have kB mean
1000 bytes instead of 1024
Florian G. Pflug wrote:
Rounding up would have the advantage that you could just specify 0
in the config file, and have postgres use the smallest value
possible.
In most algebras, dividing zero by something is still zero, so there'd
be no need to round anything.
--
Peter Eisentraut
Peter Eisentraut wrote:
Florian G. Pflug wrote:
Rounding up would have the advantage that you could just specify 0
in the config file, and have postgres use the smallest value
possible.
In most algebras, dividing zero by something is still zero, so there'd
be no need to round anything.
I
On Thu, 2006-07-27 at 17:57, Peter Eisentraut wrote:
Florian G. Pflug wrote:
Rounding up would have the advantage that you could just specify 0
in the config file, and have postgres use the smallest value
possible.
In most algebras, dividing zero by something is still zero, so there'd
Peter Eisentraut wrote:
This consideration would become much more interesting if
*any* software
product actually made use of this newer proposed convention,
but so far
I haven't seen one yet.
So we'll look at it when Oracle does it?
I think we should be leading this charge, rather
Bort, Paul wrote:
So we'll look at it when Oracle does it?
I didn't say Oracle, I said anyone. It could be Microsoft or Samba or
Red Hat or NetBSD or my VoIP phone.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of
Peter Eisentraut wrote:
I didn't say Oracle, I said anyone. It could be Microsoft or
Samba or
Red Hat or NetBSD or my VoIP phone.
OK, I did some further digging, and
(http://members.optus.net/alexey/prefBin.xhtml) has a list at the end of
the page of software that the author claims use
Peter Eisentraut wrote:
Jim Nasby wrote:
The truth is, virtually no one, even highly technical people, ever
picks nits between kB vs KiB vs KB.
The question isn't so much whether to allow KiB and such -- that would
obviously be trivial. The question is whether we want to have kB mean
1000
On Thu, Jul 27, 2006 at 05:56:15PM +0200, Peter Eisentraut wrote:
Jim Nasby wrote:
The truth is, virtually no one, even highly technical people, ever
picks nits between kB vs KiB vs KB.
The question isn't so much whether to allow KiB and such -- that would
obviously be trivial. The
Jim Nasby [EMAIL PROTECTED] writes:
First, when it comes to page values, perhaps we should allow pages/
blocks as a valid unit. That would allow people who want to to
specify things in pages and still be explicit about what they mean.
Second, lack of interest or no, I feel forcing specific
Peter Eisentraut [EMAIL PROTECTED] writes:
... The question is whether we want to have kB mean
1000 bytes instead of 1024 bytes.
In my mind, that goes against current practice.
I concur. Most of the places where we are using these units, they are
for specifying memory sizes, and *everyone*
Martijn van Oosterhout kleptog@svana.org writes:
My main problem with the kibi, mibi, etc is that they're basically
unknown.
Frankly the main problem is that they're idiotic.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of
Tom Lane wrote:
+1 on both of those. I think that pg_settings should actually show
pages as the native unit for shared_buffers et al. The current
8kb display isn't a valid unit --- consider what happens if a
program does select setting || unit from pg_settings ...
Physicists know that the
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
+1 on both of those. I think that pg_settings should actually show
pages as the native unit for shared_buffers et al. The current
8kb display isn't a valid unit --- consider what happens if a
program does select setting || unit from
Neil Conway wrote:
On Tue, 2006-07-25 at 19:00 -0400, Tom Lane wrote:
Maybe I'm missing something, but I thought it was fairly common to
use k for 1000, K for 1024, etc (mnemonic: upper case for the
larger multiplier).
Well, that only works for K vs. k: the SI prefix for mega is M
On Wed, 2006-07-26 at 08:12 +0200, Peter Eisentraut wrote:
Neil Conway wrote:
On Tue, 2006-07-25 at 19:00 -0400, Tom Lane wrote:
Maybe I'm missing something, but I thought it was fairly common to
use k for 1000, K for 1024, etc (mnemonic: upper case for the
larger multiplier).
Simon Riggs wrote:
don't ever need to say that K = 1000, AFAICS. I think we are safe to
assume that
kB = KB = kb = Kb = 1024 bytes
mB = MB = mb = Mb = 1024 * 1024 bytes
gB = GB = gb = Gb = 1024 * 1024 * 1024 bytes
There's no value in forcing the use of specific case
Simon Riggs wrote:
There's no value in forcing the use of specific case and it will be
just confusing for people.
The issue was not the case of the units, but people were suggesting that
we should enforce the use of kiB, MiB, and GiB.
--
Peter Eisentraut
Tom Lane wrote:
That seems OK for SHOW, which is mainly intended for human
consumption, but what will you do with pg_settings? For programmatic
use I think we want more predictable behavior.
I'd think that a program would not care. Or do you want a units-free
display that can be parsed as
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
That seems OK for SHOW, which is mainly intended for human
consumption, but what will you do with pg_settings? For programmatic
use I think we want more predictable behavior.
I'd think that a program would not care. Or do you want
Peter Eisentraut wrote:
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 1000 bytes do not divide up into chunks of 1024
bytes. Who
wants to explain to users that they have to write
Bort, Paul wrote:
The Linux kernel changed to the standard years ago. And that's just a
few more lines of code than PostgreSQL. (
http://kerneltrap.org/node/340 and others )
For your entertainment, here are the usage numbers from the linux-2.6.17
kernel:
kilobyte (-i) 82
kibibyte (-i) 2
Peter Eisentraut politely corrected:
For your entertainment, here are the usage numbers from the
linux-2.6.17
kernel:
kilobyte (-i) 82
kibibyte (-i) 2
megabyte (-i) 98
mebibyte (-i) 0
gigabyte (-i) 32
gibibyte (-i) 0
KB1151
kB407
KiB 181
MB
Peter Eisentraut wrote:
Bort, Paul wrote:
The Linux kernel changed to the standard years ago. And that's just a
few more lines of code than PostgreSQL. (
http://kerneltrap.org/node/340 and others )
For your entertainment, here are the usage numbers from the linux-2.6.17
kernel:
On Wed, Jul 26, 2006 at 12:17:00PM -0400, Bort, Paul wrote:
Peter Eisentraut wrote:
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 1000 bytes do not divide up into chunks of 1024
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
On Jul 27, 2006, at 6:10 , Martijn van Oosterhout wrote:
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 10 bytes,
while 102400 bytes is possible.
I've seen this mentioned a couple of times. I'm not nearly
Michael Glaesemann [EMAIL PROTECTED] writes:
I've seen this mentioned a couple of times. I'm not nearly as
familiar with these settings as I should be, but it seems to me that
if the memory size *does* need to be a integral multiple of page
size, e.g., n * page_size = memory_size, why
It seems everyone likes the units, so here are some details of the
implementation I have prepared.
Memory units are kB, MB, GB. The factor is 1024.
Time units are ms, s, min, h, d.
I intentionally did not support microseconds because that would make the
coding extremely overflow-risky, and
Peter Eisentraut [EMAIL PROTECTED] writes:
Output from SHOW uses the largest unit that fits as long as the number
is an integer.
That seems OK for SHOW, which is mainly intended for human consumption,
but what will you do with pg_settings? For programmatic use I think
we want more predictable
On Jul 26, 2006, at 6:56 , Peter Eisentraut wrote:
Memory units are kB, MB, GB. The factor is 1024.
Time units are ms, s, min, h, d.
Are units case-sensitive? I've noticed you've been consistent in your
capitalization in these posts, so I'm wondering if you're enforcing
the same case
On Jul 26, 2006, at 7:12 , Michael Glaesemann wrote:
On Jul 26, 2006, at 6:56 , Peter Eisentraut wrote:
Memory units are kB, MB, GB. The factor is 1024.
Time units are ms, s, min, h, d.
Are units case-sensitive? I've noticed you've been consistent in
your capitalization in these
Peter Eisentraut wrote:
Memory units are kB, MB, GB. The factor is 1024.
Then shouldn't the factor be 1000? If the factor is 1024, then the units
should be KiB, MiB, GiB per IEEE 1541
(http://en.wikipedia.org/wiki/IEEE_1541) and others.
I'm not trying to be pedantic, but the general
Bort, Paul wrote:
I'm not trying to be pedantic, but the general approach with -hackers
seems to be towards compliance where practical.
But in this case it's not practical.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of
Peter Eisentraut [EMAIL PROTECTED] writes:
Bort, Paul wrote:
[ 1000 vs 1024 ]
But in this case it's not practical.
Maybe I'm missing something, but I thought it was fairly common to use
k for 1000, K for 1024, etc (mnemonic: upper case for the larger
multiplier). So I'd vote for accepting KB
On Tue, 2006-07-25 at 19:00 -0400, Tom Lane wrote:
Maybe I'm missing something, but I thought it was fairly common to use
k for 1000, K for 1024, etc (mnemonic: upper case for the larger
multiplier).
Well, that only works for K vs. k: the SI prefix for mega is M (meaning
10^6), not m.
49 matches
Mail list logo
