Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()
On 15/09/16 03:45, Robert Haas wrote: On Wed, Sep 14, 2016 at 5:22 AM, Thomas Berger wrote: Today, i found the time to read all the mails in this thread, and i think i have to explain, why we decided to open a bug for this behavior. Pn Tuesday, 23. August 2016, 13:30:29 Robert Haas wrote: J. Random User: I'm having a problem! Mailing List: Gee, how big are your tables? J. Random User: Here's some pg_size_pretty output. Mailing List: Gosh, we don't know what that means, what do you have this obscure GUC set to? J. Random User: Maybe I'll just give up on SQL and use MongoDB. In fact, we had just the other way around. One of our most critical databases had some extreme bloat. Some of our internal customers was very confused, about the sizes reported by the database. This confusion has led to wrong decisions. (And a long discussion about the choice of DBMS btw) I think there is a point missing in this whole discussion, or i just didn't see it: Yeah, the behavior of "kB" is defined in the "postgresql.conf" documentation. But no _user_ reads this. There is no link or hint in the documentation of "pg_size_pretty()" [1]. Interesting. I think that our documentation should only describe the way we use unit suffixes in one central place, but other places (like pg_size_pretty) could link to that central place. I don't believe that there is any general unanimity among users or developers about the question of which suffixes devote units denominated in units of 2^10 bytes vs. 10^3 bytes. About once a year, somebody makes an argument that we're doing it wrong, but the evidence that I've seen is very mixed. So when people say that there is only one right way to do this and we are not in compliance with that one right way, I guess I just don't believe it. Not everybody likes the way we do it, but I am fairly sure that if we change it, we'll make some currently-unhappy people happy and some currently-happy people unhappy. And the people who don't care but wanted to preserve backward compatibility will all be in the latter camp. However, that is not to say that the documentation couldn't be better. Well, I started programming 1968, and was taught that 1 kilobyte was 1024 (2^10). I object to Johny-come-latelies who try and insist it is 1000. As regards 'kB' vs 'KB', I'm not too worried either way - I think consistency is more important Cheers, Gavin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()
Robert Haas writes: > Interesting. I think that our documentation should only describe the > way we use unit suffixes in one central place, but other places (like > pg_size_pretty) could link to that central place. > I don't believe that there is any general unanimity among users or > developers about the question of which suffixes devote units > denominated in units of 2^10 bytes vs. 10^3 bytes. About once a year, > somebody makes an argument that we're doing it wrong, but the evidence > that I've seen is very mixed. So when people say that there is only > one right way to do this and we are not in compliance with that one > right way, I guess I just don't believe it. Not everybody likes the > way we do it, but I am fairly sure that if we change it, we'll make > some currently-unhappy people happy and some currently-happy people > unhappy. And the people who don't care but wanted to preserve > backward compatibility will all be in the latter camp. That's about my position too: I cannot see that changing this is going to make things better to a degree that would justify breaking backwards compatibility. > However, that is not to say that the documentation couldn't be better. +1; your idea above seems sound. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()
On Wed, Sep 14, 2016 at 5:22 AM, Thomas Berger wrote: > Today, i found the time to read all the mails in this thread, and i think i > have to explain, why we decided to open a bug for this behavior. > > Pn Tuesday, 23. August 2016, 13:30:29 Robert Haas wrote: >> J. Random User: I'm having a problem! >> Mailing List: Gee, how big are your tables? >> J. Random User: Here's some pg_size_pretty output. >> Mailing List: Gosh, we don't know what that means, what do you have >> this obscure GUC set to? >> J. Random User: Maybe I'll just give up on SQL and use MongoDB. > > In fact, we had just the other way around. One of our most critical databases > had some extreme bloat. > Some of our internal customers was very confused, about the sizes reported by > the database. > This confusion has led to wrong decisions. (And a long discussion about the > choice of DBMS btw) > > I think there is a point missing in this whole discussion, or i just didn't > see it: > > Yeah, the behavior of "kB" is defined in the "postgresql.conf" documentation. > But no _user_ reads this. There is no link or hint in the documentation of > "pg_size_pretty()" [1]. Interesting. I think that our documentation should only describe the way we use unit suffixes in one central place, but other places (like pg_size_pretty) could link to that central place. I don't believe that there is any general unanimity among users or developers about the question of which suffixes devote units denominated in units of 2^10 bytes vs. 10^3 bytes. About once a year, somebody makes an argument that we're doing it wrong, but the evidence that I've seen is very mixed. So when people say that there is only one right way to do this and we are not in compliance with that one right way, I guess I just don't believe it. Not everybody likes the way we do it, but I am fairly sure that if we change it, we'll make some currently-unhappy people happy and some currently-happy people unhappy. And the people who don't care but wanted to preserve backward compatibility will all be in the latter camp. However, that is not to say that the documentation couldn't be better. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()
Today, i found the time to read all the mails in this thread, and i think i have to explain, why we decided to open a bug for this behavior. Pn Tuesday, 23. August 2016, 13:30:29 Robert Haas wrote: > J. Random User: I'm having a problem! > Mailing List: Gee, how big are your tables? > J. Random User: Here's some pg_size_pretty output. > Mailing List: Gosh, we don't know what that means, what do you have > this obscure GUC set to? > J. Random User: Maybe I'll just give up on SQL and use MongoDB. In fact, we had just the other way around. One of our most critical databases had some extreme bloat. Some of our internal customers was very confused, about the sizes reported by the database. This confusion has led to wrong decisions. (And a long discussion about the choice of DBMS btw) I think there is a point missing in this whole discussion, or i just didn't see it: Yeah, the behavior of "kB" is defined in the "postgresql.conf" documentation. But no _user_ reads this. There is no link or hint in the documentation of "pg_size_pretty()" [1]. [1] https://www.postgresql.org/docs/9.5/static/functions-admin.html#FUNCTIONS-ADMIN-DBSIZE -- Thomas Berger PostgreSQL DBA Database Operations 1&1 Telecommunication SE | Ernst-Frey-Straße 10 | 76135 Karlsruhe | Germany Phone: +49 721 91374-6566 E-Mail: thomas.ber...@1und1.de | Web: www.1und1.de Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 23963 Vorstand: Markus Huhn, Alessandro Nava, Moritz Roth, Ludger Sieverding, Martin Witt Aufsichtsratsvorsitzender: Michael Scheeren Member of United Internet Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind oder diese E-Mail irrtümlich erhalten haben, unterrichten Sie bitte den Absender und vernichten Sie diese E-Mail. Anderen als dem bestimmungsgemäßen Adressaten ist untersagt, diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient of this e-mail, you are hereby notified that saving, distribution or use of the content of this e-mail in any way is prohibited. If you have received this e-mail in error, please notify the sender and delete the e-mail. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()
On 7/30/16 2:16 PM, Bruce Momjian wrote: > The second patch does what Tom suggests above by outputting only "KB", > and it supports "kB" for backward compatibility. What it doesn't do is > to allow arbitrary case, which I think would be a step backward. The > second patch actually does match the JEDEC standard, except for allowing > "kB". Btw., just to show that I'm not all crazy, the following programs also display a small "k" for file sizes and download rates: apt curl dnf pip yum vagrant -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()
On Tue, Aug 23, 2016 at 2:33 PM, Bruce Momjian wrote: > Well, the patch was updated several times, and the final version was not > objected to until you objected. It is not clear what you mean by "the final version", because you posted two different final versions. I don't see a clear vote from anybody in favor of either of those things, and Peter's replies seem to me to suggest that he does not support either of your proposals. So I am not sure that I would agree with the statement that nobody objected, but in any case there certainly wasn't a consensus in favor of either change. Also, the subject of this thread is "wrong suffix for pg_size_pretty", which may not have tipped people off to the fact that you were proposing to replace "kB" with "KB" everywhere. Even after reading your email, I didn't realize that you were proposing that until I actually opened the patch and looked at it. Such widespread changes tend to draw objections, and IMHO shouldn't be made unless it's abundantly clear that most people are in favor. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()
Bruce Momjian wrote: > On Tue, Aug 23, 2016 at 02:31:26PM -0400, Robert Haas wrote: > > On Tue, Aug 23, 2016 at 1:57 PM, Bruce Momjian wrote: > > > That's why I was asking you to comment on the final patch, which I am > > > planning to apply to PG 10 soon. > > > > Oh, OK. I didn't understand that that was what you are asking. I > > don't find either of your proposed final patches to be an improvement > > over the status quo. I think the selection of kB rather than KB was a > > deliberate decision by Peter Eisentraut, and I don't think changing > > our practice now buys us anything meaningful. Your first patch > > introduces an odd wart into the GUC mechanism, with a strange wording > > for the message, to fix something that's not really broken in the > > first place. Your second one alters kB to KB in zillions of places > > all over the code base, and I am quite sure that there is no consensus > > to do anything of that sort. > > Well, the patch was updated several times, and the final version was not > objected to until you objected. Does anyone else want to weigh in? I think this should be left alone -- it looks more like pointless tinkering than something useful. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()
On Tue, Aug 23, 2016 at 11:35:35AM -0700, Andres Freund wrote: > On 2016-08-23 14:33:15 -0400, Bruce Momjian wrote: > > On Tue, Aug 23, 2016 at 02:31:26PM -0400, Robert Haas wrote: > > > On Tue, Aug 23, 2016 at 1:57 PM, Bruce Momjian wrote: > > > > That's why I was asking you to comment on the final patch, which I am > > > > planning to apply to PG 10 soon. > > > > > > Oh, OK. I didn't understand that that was what you are asking. I > > > don't find either of your proposed final patches to be an improvement > > > over the status quo. I think the selection of kB rather than KB was a > > > deliberate decision by Peter Eisentraut, and I don't think changing > > > our practice now buys us anything meaningful. Your first patch > > > introduces an odd wart into the GUC mechanism, with a strange wording > > > for the message, to fix something that's not really broken in the > > > first place. Your second one alters kB to KB in zillions of places > > > all over the code base, and I am quite sure that there is no consensus > > > to do anything of that sort. > > > > Well, the patch was updated several times, and the final version was not > > objected to until you objected. Does anyone else want to weigh in? > > To me the change doesn't seem beneficial. Noise aside, the added > whitespace seems even seems detrimental to me. But I also don't really > care much. Well, right now we are inconsistent, so we should decide on the spacing and make it consistent. I think we are consistent on using 'k' instead of 'K'. There were at least eight people on this thread and when no one objected to my final patch, I thought people wanted it. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()
On 2016-08-23 14:33:15 -0400, Bruce Momjian wrote: > On Tue, Aug 23, 2016 at 02:31:26PM -0400, Robert Haas wrote: > > On Tue, Aug 23, 2016 at 1:57 PM, Bruce Momjian wrote: > > > That's why I was asking you to comment on the final patch, which I am > > > planning to apply to PG 10 soon. > > > > Oh, OK. I didn't understand that that was what you are asking. I > > don't find either of your proposed final patches to be an improvement > > over the status quo. I think the selection of kB rather than KB was a > > deliberate decision by Peter Eisentraut, and I don't think changing > > our practice now buys us anything meaningful. Your first patch > > introduces an odd wart into the GUC mechanism, with a strange wording > > for the message, to fix something that's not really broken in the > > first place. Your second one alters kB to KB in zillions of places > > all over the code base, and I am quite sure that there is no consensus > > to do anything of that sort. > > Well, the patch was updated several times, and the final version was not > objected to until you objected. Does anyone else want to weigh in? To me the change doesn't seem beneficial. Noise aside, the added whitespace seems even seems detrimental to me. But I also don't really care much. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()
On Tue, Aug 23, 2016 at 02:31:26PM -0400, Robert Haas wrote: > On Tue, Aug 23, 2016 at 1:57 PM, Bruce Momjian wrote: > > That's why I was asking you to comment on the final patch, which I am > > planning to apply to PG 10 soon. > > Oh, OK. I didn't understand that that was what you are asking. I > don't find either of your proposed final patches to be an improvement > over the status quo. I think the selection of kB rather than KB was a > deliberate decision by Peter Eisentraut, and I don't think changing > our practice now buys us anything meaningful. Your first patch > introduces an odd wart into the GUC mechanism, with a strange wording > for the message, to fix something that's not really broken in the > first place. Your second one alters kB to KB in zillions of places > all over the code base, and I am quite sure that there is no consensus > to do anything of that sort. Well, the patch was updated several times, and the final version was not objected to until you objected. Does anyone else want to weigh in? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()
On Tue, Aug 23, 2016 at 1:57 PM, Bruce Momjian wrote: > That's why I was asking you to comment on the final patch, which I am > planning to apply to PG 10 soon. Oh, OK. I didn't understand that that was what you are asking. I don't find either of your proposed final patches to be an improvement over the status quo. I think the selection of kB rather than KB was a deliberate decision by Peter Eisentraut, and I don't think changing our practice now buys us anything meaningful. Your first patch introduces an odd wart into the GUC mechanism, with a strange wording for the message, to fix something that's not really broken in the first place. Your second one alters kB to KB in zillions of places all over the code base, and I am quite sure that there is no consensus to do anything of that sort. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()
On Tue, Aug 23, 2016 at 01:53:25PM -0400, Robert Haas wrote: > On Tue, Aug 23, 2016 at 1:47 PM, Bruce Momjian wrote: > >> I have already read the entire thread, and replied only after reading > >> all messages. > > > > Well, what are you replying to then? > > Your original message. I'm arguing that we should not change the > behavior, as you proposed to do. That's why I was asking you to comment on the final patch, which I am planning to apply to PG 10 soon. > > There is no GUC used, and > > everything is backward compatible. > > Greg Stark proposed a GUC. I don't think that's a good idea. You > proposed to change the behavior in a way that is not > backward-compatible. I don't think that's a good idea either. If you > are saying that you've dropped those proposals, fine, but I think it's > entirely reasonable for me to express my opinion on them. It was not > evident to me that the thread had reached any kind of consensus. Uh, the patch was the consensus, as I had several versions. It was not clear from your email what you thought of the patch, or if your comments applied to the final patch at all. The email you quoted was mine, but from a very early stage in the discussion. > > Your hyperbole about a new user > > being confused is also not helpful. What is this "chaos" you are > > talking about? > > Behavior-changing GUCs are bad news for reasons that have been > discussed many times before: they create a requirement that everybody > who writes code intended to run on arbitrary PostgreSQL installation > be prepared to cater to every possible value of that GUC. > pg_size_pretty() is pretty likely to appear in queries that we give > users to run on their systems, so it would be a particularly poor > choice to make its behavior configurable. There is no question on that point. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()
On Tue, Aug 23, 2016 at 1:47 PM, Bruce Momjian wrote: >> I have already read the entire thread, and replied only after reading >> all messages. > > Well, what are you replying to then? Your original message. I'm arguing that we should not change the behavior, as you proposed to do. > There is no GUC used, and > everything is backward compatible. Greg Stark proposed a GUC. I don't think that's a good idea. You proposed to change the behavior in a way that is not backward-compatible. I don't think that's a good idea either. If you are saying that you've dropped those proposals, fine, but I think it's entirely reasonable for me to express my opinion on them. It was not evident to me that the thread had reached any kind of consensus. > Your hyperbole about a new user > being confused is also not helpful. What is this "chaos" you are > talking about? Behavior-changing GUCs are bad news for reasons that have been discussed many times before: they create a requirement that everybody who writes code intended to run on arbitrary PostgreSQL installation be prepared to cater to every possible value of that GUC. pg_size_pretty() is pretty likely to appear in queries that we give users to run on their systems, so it would be a particularly poor choice to make its behavior configurable. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()
On Tue, Aug 23, 2016 at 01:45:44PM -0400, Robert Haas wrote: > On Tue, Aug 23, 2016 at 1:43 PM, Bruce Momjian wrote: > > On Tue, Aug 23, 2016 at 01:30:29PM -0400, Robert Haas wrote: > >> On Fri, Jul 29, 2016 at 8:18 PM, Bruce Momjian wrote: > >> > and the units were copied when pg_size_pretty() was implemented. These > >> > units are based on the International System of Units (SI)/metric. > >> > However, the SI system is power-of-10-based, and we just re-purposed > >> > them to be 1024 or 2^10-based. > >> > > >> > However, that is not the end of the story. > >> > >> Sure it is. The behavior of the code matches the documentation. The > >> documentation describes one of several reasonable behaviors. Full > >> stop. > >> > >> > I am thinking Postgres 10 would be a good time to switch to KB as a > >> > 1024-based prefix. Unfortunately, there is no similar fix for MB, GB, > >> > etc. 'm' is 'milli' so there we never used mB, so in JEDEC and Metric, > >> > MB is ambiguous as 1000-based or 1024-based. > >> > >> I think this would be a backward compatibility break that would > >> probably cause confusion for years. I think we can add new functions > >> that behave differently, but I oppose revising the behavior of the > >> existing functions ... and I *definitely* oppose adding new > >> behavior-changing GUCs. The result of that will surely be chaos. > > > > Can you read up through August 1 and then reply? > > I have already read the entire thread, and replied only after reading > all messages. Well, what are you replying to then? There is no GUC used, and everything is backward compatible. Your hyperbole about a new user being confused is also not helpful. What is this "chaos" you are talking about? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()
On Tue, Aug 23, 2016 at 1:43 PM, Bruce Momjian wrote: > On Tue, Aug 23, 2016 at 01:30:29PM -0400, Robert Haas wrote: >> On Fri, Jul 29, 2016 at 8:18 PM, Bruce Momjian wrote: >> > and the units were copied when pg_size_pretty() was implemented. These >> > units are based on the International System of Units (SI)/metric. >> > However, the SI system is power-of-10-based, and we just re-purposed >> > them to be 1024 or 2^10-based. >> > >> > However, that is not the end of the story. >> >> Sure it is. The behavior of the code matches the documentation. The >> documentation describes one of several reasonable behaviors. Full >> stop. >> >> > I am thinking Postgres 10 would be a good time to switch to KB as a >> > 1024-based prefix. Unfortunately, there is no similar fix for MB, GB, >> > etc. 'm' is 'milli' so there we never used mB, so in JEDEC and Metric, >> > MB is ambiguous as 1000-based or 1024-based. >> >> I think this would be a backward compatibility break that would >> probably cause confusion for years. I think we can add new functions >> that behave differently, but I oppose revising the behavior of the >> existing functions ... and I *definitely* oppose adding new >> behavior-changing GUCs. The result of that will surely be chaos. > > Can you read up through August 1 and then reply? I have already read the entire thread, and replied only after reading all messages. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()
On Tue, Aug 23, 2016 at 01:30:29PM -0400, Robert Haas wrote: > On Fri, Jul 29, 2016 at 8:18 PM, Bruce Momjian wrote: > > and the units were copied when pg_size_pretty() was implemented. These > > units are based on the International System of Units (SI)/metric. > > However, the SI system is power-of-10-based, and we just re-purposed > > them to be 1024 or 2^10-based. > > > > However, that is not the end of the story. > > Sure it is. The behavior of the code matches the documentation. The > documentation describes one of several reasonable behaviors. Full > stop. > > > I am thinking Postgres 10 would be a good time to switch to KB as a > > 1024-based prefix. Unfortunately, there is no similar fix for MB, GB, > > etc. 'm' is 'milli' so there we never used mB, so in JEDEC and Metric, > > MB is ambiguous as 1000-based or 1024-based. > > I think this would be a backward compatibility break that would > probably cause confusion for years. I think we can add new functions > that behave differently, but I oppose revising the behavior of the > existing functions ... and I *definitely* oppose adding new > behavior-changing GUCs. The result of that will surely be chaos. Can you read up through August 1 and then reply? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()
On Fri, Jul 29, 2016 at 8:18 PM, Bruce Momjian wrote: > The Postgres docs specify that kB is based on 1024 or 2^10: > > https://www.postgresql.org/docs/9.6/static/functions-admin.html > > Note: The units kB, MB, GB and TB used by the functions > pg_size_pretty and pg_size_bytes are defined using powers of 2 rather > than powers of 10, so 1kB is 1024 bytes, 1MB is 10242 = 1048576 bytes, > and so on. > > These prefixes were introduced to GUC variable specification in 2006: > > commit b517e653489f733893d61e7a84c118325394471c > Author: Peter Eisentraut > Date: Thu Jul 27 08:30:41 2006 + > > Allow units to be specified with configuration settings. > > and added to postgresql.conf: > > # Memory units: kB = kilobytesTime units: ms = milliseconds > #MB = megabytes s = seconds > #GB = gigabytes min = minutes > #TB = terabytes h = hours > # d = days > > and the units were copied when pg_size_pretty() was implemented. These > units are based on the International System of Units (SI)/metric. > However, the SI system is power-of-10-based, and we just re-purposed > them to be 1024 or 2^10-based. > > However, that is not the end of the story. Sure it is. The behavior of the code matches the documentation. The documentation describes one of several reasonable behaviors. Full stop. > I am thinking Postgres 10 would be a good time to switch to KB as a > 1024-based prefix. Unfortunately, there is no similar fix for MB, GB, > etc. 'm' is 'milli' so there we never used mB, so in JEDEC and Metric, > MB is ambiguous as 1000-based or 1024-based. I think this would be a backward compatibility break that would probably cause confusion for years. I think we can add new functions that behave differently, but I oppose revising the behavior of the existing functions ... and I *definitely* oppose adding new behavior-changing GUCs. The result of that will surely be chaos. J. Random User: I'm having a problem! Mailing List: Gee, how big are your tables? J. Random User: Here's some pg_size_pretty output. Mailing List: Gosh, we don't know what that means, what do you have this obscure GUC set to? J. Random User: Maybe I'll just give up on SQL and use MongoDB. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()
2016-08-01 20:51 GMT+02:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > On 7/30/16 1:18 AM, Pavel Stehule wrote: > > We talked about this issue, when I wrote function pg_size_bytes. It is > > hard to fix these functions after years of usage. The new set of > > functions can be better > > > > pg_iso_size_pretty(); > > pg_iso_size_bytes(); > > One thing that would actually be nice for other reasons as well is a > version of pg_size_pretty() that lets you specify the output unit, say, > as a second argument. Because sometimes you want to compare two tables > or something, and tells you one is 3GB and the other is 783MB, which > doesn't really help. If I tell it to use 'MB' as the output unit, I > could get comparable output. > It is looks like some convert function pg_size_to(size, unit, [others ... rounding, truncating]) returns numeric select pg_size_to(1024*1024, 'KB') Regards Pavel > -- > Peter Eisentraut http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >
Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()
On Mon, Aug 1, 2016 at 02:48:55PM -0400, Peter Eisentraut wrote: > On 7/30/16 2:16 PM, Bruce Momjian wrote: > > The second patch does what Tom suggests above by outputting only "KB", > > and it supports "kB" for backward compatibility. What it doesn't do is > > to allow arbitrary case, which I think would be a step backward. The > > second patch actually does match the JEDEC standard, except for allowing > > "kB". > > If we're going to make changes, why not bite the bullet and output KiB? > > I have never heard of JEDEC, so I'm less inclined to accept their > "standard" at this point. I already address this. While I have never heard of JEDEC either, I have seen KB, and have never seen KiB, hence my argument that KiB would lead to more confusion than we have now. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()
On 7/30/16 1:18 AM, Pavel Stehule wrote: > We talked about this issue, when I wrote function pg_size_bytes. It is > hard to fix these functions after years of usage. The new set of > functions can be better > > pg_iso_size_pretty(); > pg_iso_size_bytes(); One thing that would actually be nice for other reasons as well is a version of pg_size_pretty() that lets you specify the output unit, say, as a second argument. Because sometimes you want to compare two tables or something, and tells you one is 3GB and the other is 783MB, which doesn't really help. If I tell it to use 'MB' as the output unit, I could get comparable output. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()
On 7/30/16 2:16 PM, Bruce Momjian wrote: > The second patch does what Tom suggests above by outputting only "KB", > and it supports "kB" for backward compatibility. What it doesn't do is > to allow arbitrary case, which I think would be a step backward. The > second patch actually does match the JEDEC standard, except for allowing > "kB". If we're going to make changes, why not bite the bullet and output KiB? I have never heard of JEDEC, so I'm less inclined to accept their "standard" at this point. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()
On 07/30/2016 11:16 AM, Bruce Momjian wrote: On Sat, Jul 30, 2016 at 10:35:58AM -0400, Tom Lane wrote: Greg Stark writes: I agree that a GUC and new functions are overkill --- we should just decide on the format we want to output and what to support for input. As logical as the IEC format appears, I just don't think the Ki/Mi/Gi prefixes are used widely enough for us to use it --- I think it will cause too many problem reports: https://en.wikipedia.org/wiki/Binary_prefix I have developed two possible patches for PG 10 --- the first one merely allows "KB" to be used in addition to the existing "kB", and documents this as an option. The second patch does what Tom suggests above by outputting only "KB", and it supports "kB" for backward compatibility. What it doesn't do is to allow arbitrary case, which I think would be a step backward. The second patch actually does match the JEDEC standard, except for allowing "kB". I also just applied a doc patch that increases case and spacing consistency in the use of kB/MB/GB/TB. +1 -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development. Everyone appreciates your honesty, until you are honest with them. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()
On Sat, Jul 30, 2016 at 10:35:58AM -0400, Tom Lane wrote: > Greg Stark writes: > > I think Bruce's summary is a bit revisionist. > > I would say it's a tempest in a teapot. > > What I think we should do is accept "kb" and the rest case-insensitively, > print them all in all-upper-case always, and tell standards pedants > to get lost. The idea of introducing either a GUC or new function names > is just silly; it will cause far more confusion and user code breakage > than will result from just leaving well enough alone. I agree that a GUC and new functions are overkill --- we should just decide on the format we want to output and what to support for input. As logical as the IEC format appears, I just don't think the Ki/Mi/Gi prefixes are used widely enough for us to use it --- I think it will cause too many problem reports: https://en.wikipedia.org/wiki/Binary_prefix I have developed two possible patches for PG 10 --- the first one merely allows "KB" to be used in addition to the existing "kB", and documents this as an option. The second patch does what Tom suggests above by outputting only "KB", and it supports "kB" for backward compatibility. What it doesn't do is to allow arbitrary case, which I think would be a step backward. The second patch actually does match the JEDEC standard, except for allowing "kB". I also just applied a doc patch that increases case and spacing consistency in the use of kB/MB/GB/TB. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c new file mode 100644 index 6ac5184..40038ac *** a/src/backend/utils/misc/guc.c --- b/src/backend/utils/misc/guc.c *** typedef struct *** 694,700 #error XLOG_SEG_SIZE must be between 1MB and 1GB #endif ! static const char *memory_units_hint = gettext_noop("Valid units for this parameter are \"kB\", \"MB\", \"GB\", and \"TB\"."); static const unit_conversion memory_unit_conversion_table[] = { --- 694,700 #error XLOG_SEG_SIZE must be between 1MB and 1GB #endif ! static const char *memory_units_hint = gettext_noop("Valid units for this parameter are \"kB\"/\"KB\", \"MB\", \"GB\", and \"TB\"."); static const unit_conversion memory_unit_conversion_table[] = { *** convert_to_base_unit(int64 value, const *** 5322,5328 for (i = 0; *table[i].unit; i++) { if (base_unit == table[i].base_unit && ! strcmp(unit, table[i].unit) == 0) { if (table[i].multiplier < 0) *base_value = value / (-table[i].multiplier); --- 5322,5331 for (i = 0; *table[i].unit; i++) { if (base_unit == table[i].base_unit && ! (strcmp(unit, table[i].unit) == 0 || ! /* support the JEDEC standard which uses "KB" for 1024 */ ! (strcmp(unit, "KB") == 0 && ! strcmp(table[i].unit, "kB") == 0))) { if (table[i].multiplier < 0) *base_value = value / (-table[i].multiplier); diff --git a/configure b/configure new file mode 100755 index b49cc11..8466e5a *** a/configure --- b/configure *** Optional Packages: *** 1502,1511 --with-libs=DIRSalternative spelling of --with-libraries --with-pgport=PORTNUM set default port number [5432] --with-blocksize=BLOCKSIZE ! set table block size in kB [8] --with-segsize=SEGSIZE set table segment size in GB [1] --with-wal-blocksize=BLOCKSIZE ! set WAL block size in kB [8] --with-wal-segsize=SEGSIZE set WAL segment size in MB [16] --with-CC=CMD set compiler (deprecated) --- 1502,1511 --with-libs=DIRSalternative spelling of --with-libraries --with-pgport=PORTNUM set default port number [5432] --with-blocksize=BLOCKSIZE ! set table block size in KB [8] --with-segsize=SEGSIZE set table segment size in GB [1] --with-wal-blocksize=BLOCKSIZE ! set WAL block size in KB [8] --with-wal-segsize=SEGSIZE set WAL segment size in MB [16] --with-CC=CMD set compiler (deprecated) *** case ${blocksize} in *** 3550,3557 32) BLCKSZ=32768;; *) as_fn_error $? "Invalid block size. Allowed values are 1,2,4,8,16,32." "$LINENO" 5 esac ! { $as_echo "$as_me:${as_lineno-$LINENO}: result: ${blocksize}kB" >&5 ! $as_echo "${blocksize}kB" >&6; } cat >>confdefs.h <<_ACEOF --- 3550,3557 32) BLCKSZ=32768;; *) as_fn_error $? "Invalid block size. Allowed values are 1,2,4,8,16,32." "$LINENO" 5 esac ! { $as_echo "$as_me:${as_lineno-$LINENO}: result: ${blocksize}KB" >&5 ! $as_echo "${blocksize}KB" >&6; } cat >>confdefs.h <<_ACEOF *** case ${wal_blocksize} in *** 3638,3645
Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()
On Sat, Jul 30, 2016 at 10:35 AM, Tom Lane wrote: > Greg Stark writes: > > I think Bruce's summary is a bit revisionist. > > I would say it's a tempest in a teapot. > > What I think we should do is accept "kb" and the rest case-insensitively, > print them all in all-upper-case always, and tell standards pedants > to get lost. The idea of introducing either a GUC or new function names > is just silly; it will cause far more confusion and user code breakage > than will result from just leaving well enough alone. > I wouldn't mind fixing case sensitivity in the process...but I don't think we need to touch the GUC infrastructure at all. For a product that has a reasonably high regard for the SQL standard I'd like to at least keep an open mind about other relevant standards - and if accommodation is as simple as writing a new function I'd see no reason to reject such a patch. pg_size_pretty never did seem like a good name for a function with its behavior...lets be open to accepting an improved version without a pg_ prefix. We could even avoid a whole new function and add an "iB" template pattern to the to_char function - although I'm not sure that wouldn't be more confusing than helpful in practice. David J.
Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()
Greg Stark writes: > I think Bruce's summary is a bit revisionist. I would say it's a tempest in a teapot. What I think we should do is accept "kb" and the rest case-insensitively, print them all in all-upper-case always, and tell standards pedants to get lost. The idea of introducing either a GUC or new function names is just silly; it will cause far more confusion and user code breakage than will result from just leaving well enough alone. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()
On Sat, Jul 30, 2016 at 2:47 AM, David G. Johnston wrote: > After bouncing on this for a bit I'm inclined to mark the bug itself "won't > fix" but introduce a "to_binary_iso" function (I'm hopeful a better name > will emerge...) that will output a number using ISO binary suffixes. I > would document this under 9.8 "data type formatting functions" instead of > within system functions. I think Bruce's summary is a bit revisionist. All these standards are attempts to reconcile two different conflicting traditions that have been conflicting for decades. There's a conflict for a reason though and the tradition of using powers of 2 is well-ingrained in plenty of practices and software, not just Postgres. Personally I'm pretty satisfied with the current mode of operation because I think powers of 2 are vastly more useful and more likely to be what the user actually wants. You would be hard pressed to find any users actually typing KiB or MiB in config files and being surprised they don't work or any users typing work_mem=100MB and being surprised that they're not getting 95.367 MiB. If you really want to support a strict interpretation of the SI standards then I don't see anything wrong with having a GUC. It doesn't change the semantics of SQL parsing so the worst-case downside is that if you change the setting and then reload a config file or if you move a setting from one place in a config file to another the interpretation of the config file would change. The best practice would probably be to set this config at the top of the config file and nowhere else. I would suggest having a GUC like "strict_si_units" with false as the default. If it's true then units like KiB and KB are both accepted and mean different things. If it's false then still accept both but treat them as synonyms meaning powers of 2. This means users who don't care can continue using convenient powers of 2 everywhere without thinking about it and users who do can start using the new-fangled SI units (and have the pitfall of accidentally specifying in units of powers of 10). For outputs like pg_size_pretty, SHOW, and pg_settings you could either say to always use KiB so that the outputs are always correct to use regardless of the setting of strict_si_units or you could have it print KB et al when strict_si_units is false -- the latter have the advantage that outputs could be copied to older versions safely but the disadvantage that if you change the setting then the interpretation of existing config files change. I think it would be better to print KiB/MiB etc always. I suppose there's the alternative of trying to guess which unit results in the most concise display but that seems unnecessarily baroque and likely to just hide mistakes rather than help. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()
2016-07-30 3:47 GMT+02:00 David G. Johnston : > On Fri, Jul 29, 2016 at 8:18 PM, Bruce Momjian wrote: > >> On Tue, Jul 12, 2016 at 01:36:38PM +, thomas.ber...@1und1.de wrote: >> > The following bug has been logged on the website: >> > >> > Bug reference: 14244 >> > Logged by: Thomas Berger >> > Email address: thomas.ber...@1und1.de >> > PostgreSQL version: 9.5.3 >> > Operating system: any >> > Description: >> > >> > pg_size_pretty uses the suffix "kB" (kilobyte, 10^3 byte), but the >> returned >> > value is "KB", or "KiB" ( kibibyte, 2^10 byte). This is missleading and >> > should be fixed. See also https://en.wikipedia.org/wiki/Kibibyte >> > >> > =# select pg_size_pretty(1024000::bigint); >> > pg_size_pretty >> > >> > 1000 kB >> >> (Thread moved to hackers.) >> >> Yes, we have redefined kB, and documented its use in postgresql.conf and >> pg_size_pretty(), but it does not match any recognized standard. >> > > After bouncing on this for a bit I'm inclined to mark the bug itself > "won't fix" but introduce a "to_binary_iso" function (I'm hopeful a better > name will emerge...) that will output a number using ISO binary suffixes. > I would document this under 9.8 "data type formatting functions" instead of > within system functions. > > pg_size_pretty output can continue with a defined role to be used as input > into a GUC variable; and to keep backward compatibility. Add a note near > its definition to use "to_binary_iso" for a standard-conforming output > string. > We talked about this issue, when I wrote function pg_size_bytes. It is hard to fix these functions after years of usage. The new set of functions can be better pg_iso_size_pretty(); pg_iso_size_bytes(); or shorter name pg_isize_pretty(); pg_isize_bytes(); Regards Pavel > > David J. >
Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()
On Fri, Jul 29, 2016 at 8:18 PM, Bruce Momjian wrote: > On Tue, Jul 12, 2016 at 01:36:38PM +, thomas.ber...@1und1.de wrote: > > The following bug has been logged on the website: > > > > Bug reference: 14244 > > Logged by: Thomas Berger > > Email address: thomas.ber...@1und1.de > > PostgreSQL version: 9.5.3 > > Operating system: any > > Description: > > > > pg_size_pretty uses the suffix "kB" (kilobyte, 10^3 byte), but the > returned > > value is "KB", or "KiB" ( kibibyte, 2^10 byte). This is missleading and > > should be fixed. See also https://en.wikipedia.org/wiki/Kibibyte > > > > =# select pg_size_pretty(1024000::bigint); > > pg_size_pretty > > > > 1000 kB > > (Thread moved to hackers.) > > Yes, we have redefined kB, and documented its use in postgresql.conf and > pg_size_pretty(), but it does not match any recognized standard. > After bouncing on this for a bit I'm inclined to mark the bug itself "won't fix" but introduce a "to_binary_iso" function (I'm hopeful a better name will emerge...) that will output a number using ISO binary suffixes. I would document this under 9.8 "data type formatting functions" instead of within system functions. pg_size_pretty output can continue with a defined role to be used as input into a GUC variable; and to keep backward compatibility. Add a note near its definition to use "to_binary_iso" for a standard-conforming output string. David J.
Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()
On Fri, Jul 29, 2016 at 08:18:38PM -0400, Bruce Momjian wrote: > However, that is not the end of the story. Things have moved forward > since 2006 and there is now firm support for either KB or KiB to be > 1024-based units. This blog post explains the current state of prefix > specification: > > > http://pchelp.ricmedia.com/kilobytes-megabytes-gigabytes-terabytes-explained/ > > and here is a summary for 1000/1024-based units: > > Kilobyte (Binary, JEDEC)KB 1024 > Kilobyte (Decimal, Metric) kB 1000 > Kibibyte (Binary, IEC) KiB 1024 Oh, also, here is a Wikipedia article that has a nice chart on the top right: https://en.wikipedia.org/wiki/Binary_prefix and a post that explains some of the background: http://superuser.com/questions/938234/size-of-files-in-windows-os-its-kb-or-kb -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()
On Tue, Jul 12, 2016 at 01:36:38PM +, thomas.ber...@1und1.de wrote: > The following bug has been logged on the website: > > Bug reference: 14244 > Logged by: Thomas Berger > Email address: thomas.ber...@1und1.de > PostgreSQL version: 9.5.3 > Operating system: any > Description: > > pg_size_pretty uses the suffix "kB" (kilobyte, 10^3 byte), but the returned > value is "KB", or "KiB" ( kibibyte, 2^10 byte). This is missleading and > should be fixed. See also https://en.wikipedia.org/wiki/Kibibyte > > =# select pg_size_pretty(1024000::bigint); > pg_size_pretty > > 1000 kB (Thread moved to hackers.) The Postgres docs specify that kB is based on 1024 or 2^10: https://www.postgresql.org/docs/9.6/static/functions-admin.html Note: The units kB, MB, GB and TB used by the functions pg_size_pretty and pg_size_bytes are defined using powers of 2 rather than powers of 10, so 1kB is 1024 bytes, 1MB is 10242 = 1048576 bytes, and so on. These prefixes were introduced to GUC variable specification in 2006: commit b517e653489f733893d61e7a84c118325394471c Author: Peter Eisentraut Date: Thu Jul 27 08:30:41 2006 + Allow units to be specified with configuration settings. and added to postgresql.conf: # Memory units: kB = kilobytesTime units: ms = milliseconds #MB = megabytes s = seconds #GB = gigabytes min = minutes #TB = terabytes h = hours # d = days and the units were copied when pg_size_pretty() was implemented. These units are based on the International System of Units (SI)/metric. However, the SI system is power-of-10-based, and we just re-purposed them to be 1024 or 2^10-based. However, that is not the end of the story. Things have moved forward since 2006 and there is now firm support for either KB or KiB to be 1024-based units. This blog post explains the current state of prefix specification: http://pchelp.ricmedia.com/kilobytes-megabytes-gigabytes-terabytes-explained/ and here is a summary for 1000/1024-based units: Kilobyte (Binary, JEDEC)KB 1024 Kilobyte (Decimal, Metric) kB 1000 Kibibyte (Binary, IEC) KiB 1024 You will notice that none of these list kB as 1024, which explains this bug report. Yes, we have redefined kB, and documented its use in postgresql.conf and pg_size_pretty(), but it does not match any recognized standard. I am thinking Postgres 10 would be a good time to switch to KB as a 1024-based prefix. Unfortunately, there is no similar fix for MB, GB, etc. 'm' is 'milli' so there we never used mB, so in JEDEC and Metric, MB is ambiguous as 1000-based or 1024-based. IEC does give us a unique specification for 'mega', MiB, and GiB, which might be what we want to use, but that might be too big a change, and I rarely see those. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers