Re: [HACKERS] effective_cache_size vs units

2007-01-03 Thread Zeugswetter Andreas ADI SD

  Yes, and I can't think of a single reason why we'd let people
specify
  anything in millibytes, or kilobits.
 
 How about a configuration option related to connection throughput,
which is 
 typically measured in bits?

We'd use kbit. I don't see us using kb in that case (or was it kB
:-).

Andreas

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [HACKERS] effective_cache_size vs units

2007-01-03 Thread Jim Nasby

You just proved the case for why the units shouldn't be case sensitive:

On Dec 30, 2006, at 6:36 PM, Andrew Hammond wrote:

I agree. But perhaps the solution instead of failing is to throw a
warning to the effect of Not to be pedantic, but you said mb and
millibits as a unit doesn't make sense in this context. Assuming you
meant MB (MegaBits). and then start up.


Do we really want people specifying effective_cache_size in *bits*,  
mega or not? I think no.


To reply to Peter's comment, yes, bits would be useful if we ever  
actually have any settings relating to network bandwidth. But that's  
a really big IF. IF we do eventually decide to add such a setting, I  
think it would make the most sense to spell out 'bits' in the unit.

--
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)



---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org


Re: [HACKERS] effective_cache_size vs units

2007-01-02 Thread Peter Eisentraut
Am Donnerstag, 28. Dezember 2006 13:25 schrieb Jim C. Nasby:
 Yes, and I can't think of a single reason why we'd let people specify
 anything in millibytes, or kilobits.

How about a configuration option related to connection throughput, which is 
typically measured in bits?

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


Re: [HACKERS] effective_cache_size vs units

2007-01-02 Thread Tom Lane
Peter Eisentraut [EMAIL PROTECTED] writes:
 Am Donnerstag, 28. Dezember 2006 13:25 schrieb Jim C. Nasby:
 Yes, and I can't think of a single reason why we'd let people specify
 anything in millibytes, or kilobits.

 How about a configuration option related to connection throughput, which is 
 typically measured in bits?

But at least as often in bytes.  What's more, if the system really were
to accept both units, you could reasonably expect that people would get
it wrong at least half the time ...

regards, tom lane

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] effective_cache_size vs units

2007-01-01 Thread Benny Amorsen
 TL == Tom Lane [EMAIL PROTECTED] writes:

TL Personally I don't find the argument about someday we might want
TL to support measurements in millibits to be convincing at all, and
TL certainly it seems weaker than the argument that units should be
TL case insensitive because everything else in this file is. The SQL
TL spec has to be considered a more relevant controlling precedent
TL for us than the SI units spec, and there are no case-sensitive
TL keywords in SQL.

Units simply are not case sensitive. They are just a more or less
random collection of preexisting symbols, because that was easier than
drawing up entirely new ones. Not all are English letters, for one µ
is not. If you upper case a text with units in, the units do not
change with the rest of the text.


/Benny



---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: [HACKERS] effective_cache_size vs units

2007-01-01 Thread Tom Lane
Benny Amorsen [EMAIL PROTECTED] writes:
 TL == Tom Lane [EMAIL PROTECTED] writes:
 TL Personally I don't find the argument about someday we might want
 TL to support measurements in millibits to be convincing at all, and
 TL certainly it seems weaker than the argument that units should be
 TL case insensitive because everything else in this file is. The SQL
 TL spec has to be considered a more relevant controlling precedent
 TL for us than the SI units spec, and there are no case-sensitive
 TL keywords in SQL.

 Units simply are not case sensitive. They are just a more or less
 random collection of preexisting symbols, because that was easier than
 drawing up entirely new ones. Not all are English letters, for one µ
 is not.

You mean are case sensitive right?  This is not news.  The point I'm
basically making is that it's not going to hurt us to restrict GUC to
supporting a subset of all-possible-units that can be treated
case-insensitively.  We're already going to restrict the allowed
character set: I can guarantee you that µ, or anything else
outside 7-bit ASCII, will never be accepted.  It's just not worth the
trouble of dealing with multiple possible encodings.

regards, tom lane

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


Re: [HACKERS] effective_cache_size vs units

2006-12-30 Thread Andrew Hammond
Benny Amorsen wrote:
  TL == Tom Lane [EMAIL PROTECTED] writes:

 TL Anyone against making it case-insensitive, speak now or hold your
 TL peace.

 SI-units are inherently case-sensitive. The obvious example is that
 now you will allow people to specify an amount in millibytes, while
 interpreting it in megabytes.

And as Peter points out, there may be a desire to support SI-type units
in other parts of the database at some time in the future. It seems
like a questionable idea to break with convention just for ease of use.

 You are trying to interpret valid input as misspellings based on
 context, and then you silently guess at what the user really meant.
 That's MySQL behaviour!

I agree. But perhaps the solution instead of failing is to throw a
warning to the effect of Not to be pedantic, but you said mb and
millibits as a unit doesn't make sense in this context. Assuming you
meant MB (MegaBits). and then start up.

Generally I'm against guessing what the user really wants, but in this
case, it seems pretty difficult to guess wrong. But either way I'm
always dead set against _silently_ guessing.

Andrew


---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate


Re: [HACKERS] effective_cache_size vs units

2006-12-30 Thread Tom Lane
Andrew Hammond [EMAIL PROTECTED] writes:
 I agree. But perhaps the solution instead of failing is to throw a
 warning to the effect of Not to be pedantic, but you said mb and
 millibits as a unit doesn't make sense in this context. Assuming you
 meant MB (MegaBits). and then start up.
 Generally I'm against guessing what the user really wants, but in this
 case, it seems pretty difficult to guess wrong. But either way I'm
 always dead set against _silently_ guessing.

Bear in mind that the typical place for this sort of thing is
postgresql.conf, and for problems in that file the only place we can
emit a warning is into the postmaster log, which far too many users
never look at (if indeed it's going anywhere but /dev/null in the first
place).  So I can't get very excited about report a warning as a
compromise solution.

Personally I don't find the argument about someday we might want to
support measurements in millibits to be convincing at all, and
certainly it seems weaker than the argument that units should be case
insensitive because everything else in this file is.  The SQL spec
has to be considered a more relevant controlling precedent for us than
the SI units spec, and there are no case-sensitive keywords in SQL.

regards, tom lane

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] effective_cache_size vs units

2006-12-29 Thread Benny Amorsen
 JCN == Jim C Nasby [EMAIL PROTECTED] writes:

JCN Truth is, I bet many (if not most) DBAs barely know that case
JCN matters in the units.

Sounds like the school system needs fixing, then.


/Benny



---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate


Re: [HACKERS] effective_cache_size vs units

2006-12-29 Thread Alvaro Herrera
Benny Amorsen wrote:
  JCN == Jim C Nasby [EMAIL PROTECTED] writes:
 
 JCN Truth is, I bet many (if not most) DBAs barely know that case
 JCN matters in the units.
 
 Sounds like the school system needs fixing, then.

Sure, but it probably shows a lot more prominently in other areas than
in unit casing though.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate


Re: [HACKERS] effective_cache_size vs units

2006-12-28 Thread Jim C. Nasby
On Wed, Dec 27, 2006 at 09:39:22AM +0100, Benny Amorsen wrote:
  TL == Tom Lane [EMAIL PROTECTED] writes:
 
 TL Anyone against making it case-insensitive, speak now or hold your
 TL peace.
 
 SI-units are inherently case-sensitive. The obvious example is that
 now you will allow people to specify an amount in millibytes, while
 interpreting it in megabytes.

Yes, and I can't think of a single reason why we'd let people specify
anything in millibytes, or kilobits. Truth is, I bet many (if not most)
DBAs barely know that case matters in the units. And even those that do
are likely to prefer ease of use to pedantics.

As for the comments about SI datatypes and MySQL-isms, there's a hell of
a big difference between muddying the line in a config file for ease of
use and stomping on data that's actually stored in the database.
-- 
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate


Re: [HACKERS] effective_cache_size vs units

2006-12-27 Thread Benny Amorsen
 TL == Tom Lane [EMAIL PROTECTED] writes:

TL Anyone against making it case-insensitive, speak now or hold your
TL peace.

SI-units are inherently case-sensitive. The obvious example is that
now you will allow people to specify an amount in millibytes, while
interpreting it in megabytes.

You are trying to interpret valid input as misspellings based on
context, and then you silently guess at what the user really meant.
That's MySQL behaviour!


/Benny



---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] effective_cache_size vs units

2006-12-27 Thread tomas
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Dec 27, 2006 at 09:39:22AM +0100, Benny Amorsen wrote:
  TL == Tom Lane [EMAIL PROTECTED] writes:
 
 TL Anyone against making it case-insensitive, speak now or hold your
 TL peace.
 
 SI-units are inherently case-sensitive [...]

As a notorious lurker, set my weight to one mg (choose the case ;-)

I'd tend to keep case sensitivity, but will hold my peace regardless of
outcome.

Thanks
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFFkkDWBcgs9XrR2kYRAmKFAJwPMOwl+IbCbMQvszn9RKpXRW3N6ACfbwne
juGsqnMsj2BMyCO+BjP9hq4=
=KCiY
-END PGP SIGNATURE-


---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [HACKERS] effective_cache_size vs units

2006-12-26 Thread Joshua D. Drake
On Tue, 2006-12-19 at 22:06 -0800, Steve Atkins wrote:
 On Dec 19, 2006, at 9:50 PM, Jonah H. Harris wrote:
 
  On 12/19/06, Tom Lane [EMAIL PROTECTED] wrote:
  I think we should just accept the strings case-insensitively, too.
 
  While acknowledging Peter's pedantically-correct points, I say +1 for
  ease of use.
 
 +1. I spend some time walking people through tuning issues
 by phone or IM. Anything that complicates supporting users or
 frustrates users for no actual benefit is a bad thing.
 
 (And this is unrelated to any theoretical units-aware data type -
 we might well be interested in milliwatts and megawatts in a
 datatype,  but in the configuration file we're unlikely to ever
 need to configure things in units of millibits).

Where we at on this?


Joshua D. Drake


 
 Cheers,
Steve
 
 
 ---(end of broadcast)---
 TIP 4: Have you searched our list archives?
 
http://archives.postgresql.org
 
-- 

  === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate




---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] effective_cache_size vs units

2006-12-26 Thread Tom Lane
Joshua D. Drake [EMAIL PROTECTED] writes:
 On 12/19/06, Tom Lane [EMAIL PROTECTED] wrote:
 I think we should just accept the strings case-insensitively, too.

 Where we at on this?

Anyone against making it case-insensitive, speak now or hold your peace.

regards, tom lane

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: [HACKERS] effective_cache_size vs units

2006-12-20 Thread Tom Dunstan

Tom Lane wrote:


(Hmm, I wonder what Tom Dunstan's enum patch does about case
sensitivity...)


Currently enum labels are case sensitive. I was a bit ambivalent about 
it... case insensitivity can lead to less surprises in some cases, but 
many programming languages that have enums are case sensitive, and so 
this wouldn't be a direct map for them. OTOH, if someone's doing evil 
things like sticking labels that differ only in case into an enum, 
perhaps they *should* be dissuaded. :)


The question is where does it end, though? Should we treat letters with 
accents and umlauts as equivalent as well? Do we remove punctuation 
characters? It gets into a (for me) more murky localization issue, and 
I'm not familiar with the postgresql apis for handling that. Maybe it's 
easy.


Since we basically accept any old thing into an enum label, I think we 
probably shouldn't muck with it. If we want to have some sort of 
normalized version, then we should probably restrict the characters that 
we accept fairly severely.


Also note that enum values are far more likely to be set by application 
code than by a human typing the value in directly, so in that sense the 
need for case insensitivity seems somewhat diminished.


I suppose we should think about mysql refugees at some point, though. I 
wonder what they do. The documentation is silent on the matter (and all 
their examples are in lower case). Mysql is generally case insensitive, 
right?


Cheers

Tom

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq


Re: [HACKERS] effective_cache_size vs units

2006-12-20 Thread Kenneth Marshall
On Tue, Dec 19, 2006 at 10:12:34PM +, Gregory Stark wrote:
 
 Tom Lane [EMAIL PROTECTED] writes:
 
  Magnus Hagander [EMAIL PROTECTED] writes:
  Oh, you mean MB vs Mb. Man, it had to be that simple :)
 
  ISTM we had discussed whether guc.c should accept units strings in
  a case-insensitive manner, and the forces of pedantry won the first
  round.  Shall we reopen that argument?
 
 Nope, I just checked back in the archive and that's not what happened. There
 was an extended discussion about whether to force users to use the silly KiB,
 MiB, etc units. Thankfully the pedants lost that round soundly.
 
 There was no particular discussion about case sensitivity though Simon made
 the case for user-friendly behaviour:
 
  I think we are safe assume to 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 and it will be just
  confusing for people.
 
 http://archives.postgresql.org/pgsql-hackers/2006-07/msg01253.php
 
 And Jim Nasby said something similar:
 
  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 *functional*
  argument for it, we shouldn't do it. Wanting to enforce a convention that
  people rarely use isn't a good reason.
 
 http://archives.postgresql.org/pgsql-hackers/2006-07/msg01355.php
 
 There was a lone comment from Thomas Hallgren in favour of case sensitivity in
 the name of consistency. But Nasby's comment was directly in response and
 nobody else piped up after that.
 

My one comment is that a little 'b' is used to indicate bits normally
and a capital 'B' is used to indicate bytes. So
   kb = '1024 bits'
   kB = '1024 bytes'
...

I do think that whether or not the k/m/g is upper case or lower case
is immaterial.

Ken
 -- 
   Gregory Stark
   EnterpriseDB  http://www.enterprisedb.com
 
 ---(end of broadcast)---
 TIP 4: Have you searched our list archives?
 
http://archives.postgresql.org
 

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [HACKERS] effective_cache_size vs units

2006-12-20 Thread Peter Eisentraut
Am Mittwoch, 20. Dezember 2006 13:42 schrieb Tom Dunstan:
 I suppose we should think about mysql refugees at some point, though. I
 wonder what they do. The documentation is silent on the matter (and all
 their examples are in lower case). Mysql is generally case insensitive,
 right?

Maybe you can make sense of this, but I can't ...


mysql create table test (a int, b enum ('x', 'X', 'y'));
Query OK, 0 rows affected, 1 warning (0.02 sec)

mysql show warnings;
+---+--+-+
| Level | Code | Message |
+---+--+-+
| Note  | 1291 | Column 'b' has duplicated value 'x' in ENUM |
+---+--+-+
1 row in set (0.00 sec)

mysql insert into test values (1, 'x');
Query OK, 1 row affected (0.00 sec)

mysql insert into test values (1, 'X');
Query OK, 1 row affected (0.00 sec)

mysql insert into test values (1, 'y');
Query OK, 1 row affected (0.00 sec)

mysql insert into test values (1, 'Y');
Query OK, 1 row affected (0.00 sec)

mysql insert into test values (1, 'z');
Query OK, 1 row affected, 1 warning (0.00 sec)

## You think that was funny -- now watch this:

mysql select * from test;
+--+--+
| a| b|
+--+--+
|1 | x|
|1 | x|
|1 | y|
|1 | y|
|1 |  |
+--+--+
5 rows in set (0.00 sec)

mysql drop table test;
Query OK, 0 rows affected (0.00 sec)

mysql create table test (a int, b enum ('ä', 'Ä', ' ', '  '));
## Above is a-diaeresis, A-diaeresis.
Query OK, 0 rows affected, 2 warnings (0.00 sec)

mysql show warnings;
+---+--+-+
| Level | Code | Message |
+---+--+-+
| Note  | 1291 | Column 'b' has duplicated value '?' in ENUM | # literal ?
| Note  | 1291 | Column 'b' has duplicated value '' in ENUM  |
+---+--+-+
2 rows in set (0.00 sec)

mysql insert into test values (1, ' ');
Query OK, 1 row affected (0.00 sec)

mysql insert into test values (1, '  ');
Query OK, 1 row affected (0.00 sec)

mysql insert into test values (1, '   ');
Query OK, 1 row affected (0.01 sec)

mysql insert into test values (1, '   |');
Query OK, 1 row affected, 1 warning (0.00 sec)

mysql show warnings;
+-+--++
| Level   | Code | Message|
+-+--++
| Warning | 1265 | Data truncated for column 'b' at row 1 |
+-+--++
1 row in set (0.00 sec)

mysql select distinct * from test;
+--+--+
| a| b|
+--+--+
|1 | ä|
|1 |  |
|1 |  |
+--+--+


Better not imitate that.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] effective_cache_size vs units

2006-12-20 Thread Andrew Dunstan

Peter Eisentraut wrote:

Am Mittwoch, 20. Dezember 2006 13:42 schrieb Tom Dunstan:
  

I suppose we should think about mysql refugees at some point, though. I
wonder what they do. The documentation is silent on the matter (and all
their examples are in lower case). Mysql is generally case insensitive,
right?



Maybe you can make sense of this, but I can't ...


  

[lots of amusing non-orthogonal braindead stuff ...]


Better not imitate that.

  


The MySQL treatment of enums is generally quite reprehensible. The 
proposed patch by contrast fits quite well into our existing type 
system, I think. MySQL users migrating will have a bit of work to do.


I don't think their experience has much to teach us (except how not to 
do enums). We should decide on case sensitivity without having reference 
to it.


cheers

andrew

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] effective_cache_size vs units

2006-12-19 Thread Magnus Hagander
On Mon, Dec 18, 2006 at 08:56:22PM -0800, Joshua D. Drake wrote:
 On Mon, 2006-12-18 at 23:46 -0500, Tom Lane wrote:
  Magnus Hagander [EMAIL PROTECTED] writes:
   Oh, you mean MB vs Mb. Man, it had to be that simple :)
  
  ISTM we had discussed whether guc.c should accept units strings in
  a case-insensitive manner, and the forces of pedantry won the first
  round.  Shall we reopen that argument?
 
 I don't think that anyone is going to think, oh I am using 1000 Mega Bit
 of ram. Mb == MB in this case. That being said, it is documented and I
 don't know that it makes that much difference as long as the
 documentation is clear.

Is it possible to add an error hint to the message? Along the line of
HINT: Did you perhaps get your casing wrong (with better wording, of
course).

//Magnus

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: [HACKERS] effective_cache_size vs units

2006-12-19 Thread Peter Eisentraut
Magnus Hagander wrote:
 Is it possible to add an error hint to the message? Along the line of
 HINT: Did you perhaps get your casing wrong (with better wording,
 of course).

Or how about we just make everything case-insensitive -- but 
case-preserving! -- on Windows only?

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] effective_cache_size vs units

2006-12-19 Thread Magnus Hagander
On Tue, Dec 19, 2006 at 10:01:05AM +0100, Peter Eisentraut wrote:
 Magnus Hagander wrote:
  Is it possible to add an error hint to the message? Along the line of
  HINT: Did you perhaps get your casing wrong (with better wording,
  of course).
 
 Or how about we just make everything case-insensitive -- but 
 case-preserving! -- on Windows only?

Wouldn't help me one bit, I had this problem on the install for
search.postgresql.org, which runs on Ubuntu Linux.

//Magnus

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] effective_cache_size vs units

2006-12-19 Thread Joshua D. Drake
On Tue, 2006-12-19 at 10:01 +0100, Peter Eisentraut wrote:
 Magnus Hagander wrote:
  Is it possible to add an error hint to the message? Along the line of
  HINT: Did you perhaps get your casing wrong (with better wording,
  of course).
 
 Or how about we just make everything case-insensitive -- but 
 case-preserving! -- on Windows only?

Or we could simply add a helpful line to the postgresql.conf.

Sincerely,

Joshua D. Drake


 
-- 

  === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate




---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] effective_cache_size vs units

2006-12-19 Thread Joshua D. Drake
On Tue, 2006-12-19 at 13:32 -0800, Joshua D. Drake wrote:
 On Tue, 2006-12-19 at 10:01 +0100, Peter Eisentraut wrote:
  Magnus Hagander wrote:
   Is it possible to add an error hint to the message? Along the line of
   HINT: Did you perhaps get your casing wrong (with better wording,
   of course).
  
  Or how about we just make everything case-insensitive -- but 
  case-preserving! -- on Windows only?
 
 Or we could simply add a helpful line to the postgresql.conf.


Index: postgresql.conf.sample
===
RCS
file: /projects/cvsroot/pgsql/src/backend/utils/misc/postgresql.conf.sample,v
retrieving revision 1.199
diff -c -r1.199 postgresql.conf.sample
*** postgresql.conf.sample  21 Nov 2006 01:23:37 -  1.199
--- postgresql.conf.sample  19 Dec 2006 21:36:28 -
***
*** 24,29 
--- 24,33 
  # settings, which are marked below, require a server shutdown and
restart
  # to take effect.
  
+ #
+ # Any memory setting may use a shortened notation such as 1024MB or
1GB.
+ # Please take note of the case next to the unit size.
+ #
  

#---
# FILE LOCATIONS


 
 Sincerely,
 
 Joshua D. Drake
 
 
  
-- 

  === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate




---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate


Re: [HACKERS] effective_cache_size vs units

2006-12-19 Thread Bruce Momjian
Joshua D. Drake wrote:
 On Tue, 2006-12-19 at 10:01 +0100, Peter Eisentraut wrote:
  Magnus Hagander wrote:
   Is it possible to add an error hint to the message? Along the line of
   HINT: Did you perhaps get your casing wrong (with better wording,
   of course).
  
  Or how about we just make everything case-insensitive -- but 
  case-preserving! -- on Windows only?
 
 Or we could simply add a helpful line to the postgresql.conf.

Looking at the documentation I see:

(possibly different) unit can also be specified explicitly.  Valid
memory units are literalkB/literal (kilobytes),
literalMB/literal (megabytes), and literalGB/literal
(gigabytes); valid time units are literalms/literal
(milliseconds), literals/literal (seconds),
literalmin/literal (minutes), literalh/literal (hours),
and literald/literal (days).  Note that the multiplier for
memory units is 1024, not 1000.

The only value to being case-sensitive in this area is to allow
upper/lower case with different meanings, but I don't see us using that,
so why do we bother caring about the case?

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] effective_cache_size vs units

2006-12-19 Thread Joshua D. Drake
On Tue, 2006-12-19 at 16:47 -0500, Bruce Momjian wrote:
 Joshua D. Drake wrote:
  On Tue, 2006-12-19 at 10:01 +0100, Peter Eisentraut wrote:
   Magnus Hagander wrote:
Is it possible to add an error hint to the message? Along the line of
HINT: Did you perhaps get your casing wrong (with better wording,
of course).
   
   Or how about we just make everything case-insensitive -- but 
   case-preserving! -- on Windows only?
  
  Or we could simply add a helpful line to the postgresql.conf.
 
 Looking at the documentation I see:
 
 (possibly different) unit can also be specified explicitly.  Valid
 memory units are literalkB/literal (kilobytes),
 literalMB/literal (megabytes), and literalGB/literal
 (gigabytes); valid time units are literalms/literal
 (milliseconds), literals/literal (seconds),
 literalmin/literal (minutes), literalh/literal (hours),
 and literald/literal (days).  Note that the multiplier for
 memory units is 1024, not 1000.
 
 The only value to being case-sensitive in this area is to allow
 upper/lower case with different meanings, but I don't see us using that,
 so why do we bother caring about the case?

Because it is technically correct :).

Sincerely,

Joshua D. Drake

 
-- 

  === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate




---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [HACKERS] effective_cache_size vs units

2006-12-19 Thread Peter Eisentraut
Joshua D. Drake wrote:
 + #
 + # Any memory setting may use a shortened notation such as 1024MB or
 1GB.
 + # Please take note of the case next to the unit size.
 + #

Well, if you add that, you should also list all the other valid units.  
But it's quite redundant, because nearly all the parameters that take 
units are already listed with units in the default file.  (Which makes 
Magnus's mistake all the more curios.)

In my mind, this is pretty silly.  There is no reputable precedent 
anywhere for variant capitalization in unit names.  Next thing we point 
out that zeros are significant in the interior of numbers, or what?

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: [HACKERS] effective_cache_size vs units

2006-12-19 Thread Joshua D. Drake
On Tue, 2006-12-19 at 22:59 +0100, Peter Eisentraut wrote:
 Joshua D. Drake wrote:
  + #
  + # Any memory setting may use a shortened notation such as 1024MB or
  1GB.
  + # Please take note of the case next to the unit size.
  + #
 
 Well, if you add that, you should also list all the other valid units.  

Why? It is clearly just an example.

 But it's quite redundant, because nearly all the parameters that take 
 units are already listed with units in the default file.  (Which makes 
 Magnus's mistake all the more curios.)

Not really, most people I know don't even consider the difference
between MB and Mb... shoot most people think that 1000MB equals one
Gigabyte.

 
 In my mind, this is pretty silly.  There is no reputable precedent 
 anywhere for variant capitalization in unit names.

I am not suggestion variant capitalization. I am suggestion a simple
document patch to help eliminate what may not be obvious.

Sincerely,

Joshua D. Drake

-- 

  === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate




---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] effective_cache_size vs units

2006-12-19 Thread Magnus Hagander
Peter Eisentraut wrote:
 Joshua D. Drake wrote:
 + #
 + # Any memory setting may use a shortened notation such as 1024MB or
 1GB.
 + # Please take note of the case next to the unit size.
 + #
 
 Well, if you add that, you should also list all the other valid units.  
 But it's quite redundant, because nearly all the parameters that take 
 units are already listed with units in the default file.  (Which makes 
 Magnus's mistake all the more curios.)
 

The explanation is pretty simple. I was in a hurry to set it, just
opened the file up in vi, jumped to effective cache size, and set it. I
remembered that hey, I can spec it in Mb now, I don't have to think,
brilliant, and just typed it in. Restarted pg and noticed it wouldn't
start...

Had I actually read through all the documentation before I did it, it
certainly wouldn't have been a problem. I doubt many users actually do
that, though. In most cases, I just assume they would just assume they
can't use units on it because the default value in the file doesn't have
units.

And frankly, this is the only case I can recall having seen when the
input is actually case sensitive between Mb and MB. Could be that I'm
not exposed to enough systems that take such input, but I can't imagine
there aren't others who would make the same mistake.

//Magnus

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: [HACKERS] effective_cache_size vs units

2006-12-19 Thread Peter Eisentraut
Bruce Momjian wrote:
 The only value to being case-sensitive in this area is to allow
 upper/lower case with different meanings, but I don't see us using
 that, so why do we bother caring about the case?

Because the units are what they are.

In broader terms, we may one day want to have other units or a 
units-aware data type, so introducing incompatibilities now would be 
unfortunate.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] effective_cache_size vs units

2006-12-19 Thread Joshua D. Drake

  In my mind, this is pretty silly.  There is no reputable precedent 
  anywhere for variant capitalization in unit names.
 
 I am not suggestion variant capitalization. I am suggestion a simple
 document patch to help eliminate what may not be obvious.

Good lord... *suggesting*

Joshua D. Drake

 Sincerely,
 
 Joshua D. Drake
 
-- 

  === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate




---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] effective_cache_size vs units

2006-12-19 Thread Gregory Stark

Tom Lane [EMAIL PROTECTED] writes:

 Magnus Hagander [EMAIL PROTECTED] writes:
 Oh, you mean MB vs Mb. Man, it had to be that simple :)

 ISTM we had discussed whether guc.c should accept units strings in
 a case-insensitive manner, and the forces of pedantry won the first
 round.  Shall we reopen that argument?

Nope, I just checked back in the archive and that's not what happened. There
was an extended discussion about whether to force users to use the silly KiB,
MiB, etc units. Thankfully the pedants lost that round soundly.

There was no particular discussion about case sensitivity though Simon made
the case for user-friendly behaviour:

 I think we are safe assume to 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 and it will be just
 confusing for people.

http://archives.postgresql.org/pgsql-hackers/2006-07/msg01253.php

And Jim Nasby said something similar:

 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 *functional*
 argument for it, we shouldn't do it. Wanting to enforce a convention that
 people rarely use isn't a good reason.

http://archives.postgresql.org/pgsql-hackers/2006-07/msg01355.php

There was a lone comment from Thomas Hallgren in favour of case sensitivity in
the name of consistency. But Nasby's comment was directly in response and
nobody else piped up after that.

-- 
  Gregory Stark
  EnterpriseDB  http://www.enterprisedb.com

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: [HACKERS] effective_cache_size vs units

2006-12-19 Thread Peter Eisentraut
Magnus Hagander wrote:
 In most cases, I just assume they would just assume
 they can't use units on it because the default value in the file
 doesn't have units.

But the default value *does* have units.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [HACKERS] effective_cache_size vs units

2006-12-19 Thread Magnus Hagander
Peter Eisentraut wrote:
 Magnus Hagander wrote:
 In most cases, I just assume they would just assume
 they can't use units on it because the default value in the file
 doesn't have units.
 
 But the default value *does* have units.
 
It does? Didn't in my file. I must've overwritten it with a config file
from some earlier beta (or snapshot) that didn't have it or so - my
default value certainly didn't have it ;-)

//Magnus

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: [HACKERS] effective_cache_size vs units

2006-12-19 Thread Joshua D. Drake
On Tue, 2006-12-19 at 23:39 +0100, Magnus Hagander wrote:
 Peter Eisentraut wrote:
  Magnus Hagander wrote:
  In most cases, I just assume they would just assume
  they can't use units on it because the default value in the file
  doesn't have units.
  
  But the default value *does* have units.
  
 It does? Didn't in my file. I must've overwritten it with a config file
 from some earlier beta (or snapshot) that didn't have it or so - my
 default value certainly didn't have it ;-)

Just to confirm, yes the sample I submitted a patch for does have units.

Joshua D. Drake


 
 //Magnus
 
-- 

  === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate




---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


Re: [HACKERS] effective_cache_size vs units

2006-12-19 Thread Peter Eisentraut
Joshua D. Drake wrote:
 I am not suggestion variant capitalization. I am suggestion a simple
 document patch to help eliminate what may not be obvious.

Perhaps it would be more effective to clarify the error message?  Right 
now it just says something to the effect of invalid integer.  I'd 
imagine invalid memory unit: TB would be less confusing.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


Re: [HACKERS] effective_cache_size vs units

2006-12-19 Thread Gregory Stark

Kenneth Marshall [EMAIL PROTECTED] writes:

 My one comment is that a little 'b' is used to indicate bits normally
 and a capital 'B' is used to indicate bytes. So
kb = '1024 bits'
kB = '1024 bytes'
 I do think that whether or not the k/m/g is upper case or lower case
 is immaterial.

Yes, well, no actually there are standard capitalizations for the k and M and
G. A lowercase g is a gram and a lowercase m means milli-.

But I think that only gets you as far as concluding that Postgres ought to
consistently use kB MB and GB in its own output. Which afaik it does.

To reach a conclusion about whether it should restrict valid user input
similarly you would have to make some sort of argument about what problems it
could lead to if we allow users to be sloppy.

I could see such an argument being made but it requires a lot of speculation
about hypothetical future parameters and future problems. When we have known
real problems today.

And yes, btw, the case sensitivity of these units had already surprised and
bothered me earlier and I failed to mention it at the time.


-- 
  Gregory Stark
  EnterpriseDB  http://www.enterprisedb.com

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: [HACKERS] effective_cache_size vs units

2006-12-19 Thread Bruce Momjian
Gregory Stark wrote:
 
 Kenneth Marshall [EMAIL PROTECTED] writes:
 
  My one comment is that a little 'b' is used to indicate bits normally
  and a capital 'B' is used to indicate bytes. So
 kb = '1024 bits'
 kB = '1024 bytes'
  I do think that whether or not the k/m/g is upper case or lower case
  is immaterial.
 
 Yes, well, no actually there are standard capitalizations for the k and M and
 G. A lowercase g is a gram and a lowercase m means milli-.

I will have 150 grams of shared memory, please.

 But I think that only gets you as far as concluding that Postgres ought to
 consistently use kB MB and GB in its own output. Which afaik it does.
 
 To reach a conclusion about whether it should restrict valid user input
 similarly you would have to make some sort of argument about what problems it
 could lead to if we allow users to be sloppy.
 
 I could see such an argument being made but it requires a lot of speculation
 about hypothetical future parameters and future problems. When we have known
 real problems today.
 
 And yes, btw, the case sensitivity of these units had already surprised and
 bothered me earlier and I failed to mention it at the time.

Agreed.  However, I see 'ms' as milliseconds, so perhaps the M vs. m is
already in use.  I think we at least need to document the case
sensitivity and improve the error message.

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: [HACKERS] effective_cache_size vs units

2006-12-19 Thread Tom Lane
Peter Eisentraut [EMAIL PROTECTED] writes:
 Perhaps it would be more effective to clarify the error message?  Right 
 now it just says something to the effect of invalid integer.  I'd 
 imagine invalid memory unit: TB would be less confusing.

+1 on that, but I think we should just accept the strings
case-insensitively, too.  SQL in general is not case sensitive for
keywords, and neither is anything else in the postgresql.conf file,
so I argue it's inconsistent to be strict about the case for units.

Nor do I believe that we'd ever accept a future patch that made
the distinction between kb and kB significant --- if you think
people are confused now, just imagine what would happen then.

regards, tom lane

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


Re: [HACKERS] effective_cache_size vs units

2006-12-19 Thread Joshua D. Drake
On Tue, 2006-12-19 at 19:16 -0500, Tom Lane wrote:
 Peter Eisentraut [EMAIL PROTECTED] writes:
  Perhaps it would be more effective to clarify the error message?  Right 
  now it just says something to the effect of invalid integer.  I'd 
  imagine invalid memory unit: TB would be less confusing.
 
 +1 on that, but I think we should just accept the strings
 case-insensitively, too.  SQL in general is not case sensitive for
 keywords, and neither is anything else in the postgresql.conf file,
 so I argue it's inconsistent to be strict about the case for units.

Hello,

Attached is a simple patch that replaces strcmp() with pg_strcasecmp().
Thanks to AndrewS for pointing out that I shouldn't use strcasecp().

I compiled and installed, ran an initdb with 32mb (versus 32MB) and it
seems to work correctly with a show shared_buffers;

Sincerely,

Joshua D. Drake




-- 

  === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate


Index: guc.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/misc/guc.c,v
retrieving revision 1.362
diff -c -r1.362 guc.c
*** guc.c	13 Dec 2006 05:54:48 -	1.362
--- guc.c	20 Dec 2006 00:59:15 -
***
*** 3630,3647 
  		while (*endptr == ' ')
  			endptr++;
  
! 		if (strcmp(endptr, kB) == 0)
  		{
  			used = true;
  			endptr += 2;
  		}
! 		else if (strcmp(endptr, MB) == 0)
  		{
  			val *= KB_PER_MB;
  			used = true;
  			endptr += 2;
  		}
! 		else if (strcmp(endptr, GB) == 0)
  		{
  			val *= KB_PER_GB;
  			used = true;
--- 3630,3647 
  		while (*endptr == ' ')
  			endptr++;
  
! 		if (pg_strcasecmp(endptr, kB) == 0)
  		{
  			used = true;
  			endptr += 2;
  		}
! 		else if (pg_strcasecmp(endptr, MB) == 0)
  		{
  			val *= KB_PER_MB;
  			used = true;
  			endptr += 2;
  		}
! 		else if (pg_strcasecmp(endptr, GB) == 0)
  		{
  			val *= KB_PER_GB;
  			used = true;
***
*** 3669,3698 
  		while (*endptr == ' ')
  			endptr++;
  
! 		if (strcmp(endptr, ms) == 0)
  		{
  			used = true;
  			endptr += 2;
  		}
! 		else if (strcmp(endptr, s) == 0)
  		{
  			val *= MS_PER_S;
  			used = true;
  			endptr += 1;
  		}
! 		else if (strcmp(endptr, min) == 0)
  		{
  			val *= MS_PER_MIN;
  			used = true;
  			endptr += 3;
  		}
! 		else if (strcmp(endptr, h) == 0)
  		{
  			val *= MS_PER_H;
  			used = true;
  			endptr += 1;
  		}
! 		else if (strcmp(endptr, d) == 0)
  		{
  			val *= MS_PER_D;
  			used = true;
--- 3669,3698 
  		while (*endptr == ' ')
  			endptr++;
  
! 		if (pg_strcasecmp(endptr, ms) == 0)
  		{
  			used = true;
  			endptr += 2;
  		}
! 		else if (pg_strcasecmp(endptr, s) == 0)
  		{
  			val *= MS_PER_S;
  			used = true;
  			endptr += 1;
  		}
! 		else if (pg_strcasecmp(endptr, min) == 0)
  		{
  			val *= MS_PER_MIN;
  			used = true;
  			endptr += 3;
  		}
! 		else if (pg_strcasecmp(endptr, h) == 0)
  		{
  			val *= MS_PER_H;
  			used = true;
  			endptr += 1;
  		}
! 		else if (pg_strcasecmp(endptr, d) == 0)
  		{
  			val *= MS_PER_D;
  			used = true;

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [HACKERS] effective_cache_size vs units

2006-12-19 Thread Peter Eisentraut
Tom Lane wrote:
 Nor do I believe that we'd ever accept a future patch that made
 the distinction between kb and kB significant --- if you think
 people are confused now, just imagine what would happen then.

As I said elsewhere, I'd imagine future functionality like a units-aware 
data type, which has been talked about several times, and then this 
would be really bad.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: [HACKERS] effective_cache_size vs units

2006-12-19 Thread Peter Eisentraut
Joshua D. Drake wrote:
 I compiled and installed, ran an initdb with 32mb (versus 32MB) and
 it seems to work correctly with a show shared_buffers;

Did it actually allocate 32 millibits of shared buffers?

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: [HACKERS] effective_cache_size vs units

2006-12-19 Thread Peter Eisentraut
Tom Lane wrote:
 +1 on that, but I think we should just accept the strings
 case-insensitively, too.

I think if we'd allow this to spread, documentation, example files and 
other material would use it inconsistently, and even more people would 
be confused and it would make us look silly.

It's not like anyone has pointed out a real use case here.  The default 
file has the units already, so it's not like they're hard to guess.  
And Magnus's issue was that the error message was confusing.  So let's 
fix that.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: [HACKERS] effective_cache_size vs units

2006-12-19 Thread Joshua D. Drake
On Wed, 2006-12-20 at 02:19 +0100, Peter Eisentraut wrote:
 Joshua D. Drake wrote:
  I compiled and installed, ran an initdb with 32mb (versus 32MB) and
  it seems to work correctly with a show shared_buffers;
 
 Did it actually allocate 32 millibits of shared buffers?

Funny :)

Joshua D. Drake



 
-- 

  === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate




---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate


Re: [HACKERS] effective_cache_size vs units

2006-12-19 Thread Joshua D. Drake

 Hello,
 
 Attached is a simple patch that replaces strcmp() with pg_strcasecmp().
 Thanks to AndrewS for pointing out that I shouldn't use strcasecp().
 

That should be AndrewD :)

J


 I compiled and installed, ran an initdb with 32mb (versus 32MB) and it
 seems to work correctly with a show shared_buffers;
 
 Sincerely,
 
 Joshua D. Drake
 
 
 
 
 ---(end of broadcast)---
 TIP 3: Have you checked our extensive FAQ?
 
http://www.postgresql.org/docs/faq
-- 

  === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate




---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] effective_cache_size vs units

2006-12-19 Thread Tom Lane
Peter Eisentraut [EMAIL PROTECTED] writes:
 Tom Lane wrote:
 Nor do I believe that we'd ever accept a future patch that made
 the distinction between kb and kB significant --- if you think
 people are confused now, just imagine what would happen then.

 As I said elsewhere, I'd imagine future functionality like a units-aware 
 data type, which has been talked about several times, and then this 
 would be really bad.

Only if the units-aware datatype insisted on case-sensitive units, which
is at variance with the SQL spec's treatment of keywords, the existing
practice in postgresql.conf, the existing practice in our datatypes such
as timestamp and interval:

regression=# select '20-dec-2006'::timestamp;
  timestamp  
-
 2006-12-20 00:00:00
(1 row)

regression=# select '20-DEC-2006'::timestamp;
  timestamp  
-
 2006-12-20 00:00:00
(1 row)

regression=# select '20-Dec-2006 America/New_York'::timestamptz;
  timestamptz   

 2006-12-20 00:00:00-05
(1 row)

regression=# select '20-Dec-2006 AMERICA/NEW_york'::timestamptz;
  timestamptz   

 2006-12-20 00:00:00-05
(1 row)

regression=# select '20-Dec-2006 PST'::timestamptz;
  timestamptz   

 2006-12-20 03:00:00-05
(1 row)

regression=# select '20-Dec-2006 pst'::timestamptz;
  timestamptz   

 2006-12-20 03:00:00-05
(1 row)

regression=# select '1 day'::interval;
 interval 
--
 1 day
(1 row)

regression=# select '1 DAY'::interval;
 interval 
--
 1 day
(1 row)

and in general, there is simply not any other part of Postgres or SQL
that you can point to that supports the idea that case sensitivity
for keywords is expected behavior.  So I think we'd flat-out reject
any such datatype.

(Hmm, I wonder what Tom Dunstan's enum patch does about case
sensitivity...)

regards, tom lane

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] effective_cache_size vs units

2006-12-19 Thread Shane Ambler

Peter Eisentraut wrote:

Tom Lane wrote:

Nor do I believe that we'd ever accept a future patch that made
the distinction between kb and kB significant --- if you think
people are confused now, just imagine what would happen then.


As I said elsewhere, I'd imagine future functionality like a units-aware 
data type, which has been talked about several times, and then this 
would be really bad.




Most if not all of us here with computer knowledge (particularly at the 
programming level) know the difference between capital and lowercase 
memory/data size abbreviations.


Case insensitive size measurements don't matter if you actually know 
what the abbreviations mean.


The case where case matters ;-) is b and B (bits and Bytes for those 
that don't know the diff)


And if you don't know the difference between m and M - one is a portion 
of and the other is a multiple of. So mB would technically mean 0.001 of 
a byte. I'd like to see you allocate that!!


As is the case of many english words - the context of the usage makes a 
big difference in the interpretation.


Given that the purpose of the effective_cache_size setting (and similar) 
is to specify the amount of memory you want allocated/limited to, then 
that context allows you to assume that all unit abbreviations are 
specifying bytes/kilobytes/megabytes/gigabytes and not 
bits/kilobits/millibits/millibytes etc



As for the future - well, TB is getting more common, petabytes of 
storage has been talked about, 64bit systems can access exabytes of ram. 
Next would be zettabytes and yottabytes.


Unless we start a roman numeral system for amounts bigger than that then 
I seriously doubt that we will hit any confusion with future usage. (and 
I doubt in our lifetimes) Though I suppose with storage expansion rates 
increasing the way they have the last few years we may be using 
yottabyte hard drives on our 256bit systems with 512 zettabytes of ram 
in about 15 years ;-)


That might make it around the end of life for the 8.0 branch so maybe we 
need to consider handling these future storage needs soon?


Maybe in 40 years we will all retire with mega-yotta-byte drives in our 
pda watches?



As for units aware datatypes - what options are available will need to 
be decided at implementation time. Will we allow megabit (Mb) size 
allocations or only megabyte? I would say bits would be clearly 
specified as such (bit instead of b)




Let's skip any flame wars on this and concentrate on the humorous future 
storage sizes.



--

Shane Ambler
[EMAIL PROTECTED]

Get Sheeky @ http://Sheeky.Biz

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

   http://www.postgresql.org/about/donate


Re: [HACKERS] effective_cache_size vs units

2006-12-19 Thread Jonah H. Harris

On 12/19/06, Tom Lane [EMAIL PROTECTED] wrote:

I think we should just accept the strings case-insensitively, too.


While acknowledging Peter's pedantically-correct points, I say +1 for
ease of use.

--
Jonah H. Harris, Software Architect | phone: 732.331.1324
EnterpriseDB Corporation| fax: 732.331.1301
33 Wood Ave S, 3rd Floor| [EMAIL PROTECTED]
Iselin, New Jersey 08830| http://www.enterprisedb.com/

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

   http://www.postgresql.org/about/donate


Re: [HACKERS] effective_cache_size vs units

2006-12-19 Thread Steve Atkins


On Dec 19, 2006, at 9:50 PM, Jonah H. Harris wrote:


On 12/19/06, Tom Lane [EMAIL PROTECTED] wrote:

I think we should just accept the strings case-insensitively, too.


While acknowledging Peter's pedantically-correct points, I say +1 for
ease of use.


+1. I spend some time walking people through tuning issues
by phone or IM. Anything that complicates supporting users or
frustrates users for no actual benefit is a bad thing.

(And this is unrelated to any theoretical units-aware data type -
we might well be interested in milliwatts and megawatts in a
datatype,  but in the configuration file we're unlikely to ever
need to configure things in units of millibits).

Cheers,
  Steve


---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org


Re: [HACKERS] effective_cache_size vs units

2006-12-18 Thread Peter Eisentraut
Magnus Hagander wrote:
 Is there any special reason why I can't use Mb and Gb and such
 for effective_cache_size, the way I can for say shared_buffers?

You can't use Mb or Gb for shared_buffers either, because those are 
not accepted units.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] effective_cache_size vs units

2006-12-18 Thread Joshua D. Drake
On Mon, 2006-12-18 at 22:08 +0100, Peter Eisentraut wrote:
 Magnus Hagander wrote:
  Is there any special reason why I can't use Mb and Gb and such
  for effective_cache_size, the way I can for say shared_buffers?
 
 You can't use Mb or Gb for shared_buffers either, because those are 
 not accepted units.

Magnus,

Here is a link that may help:
http://www.postgresql.org/docs/8.2/static/config-setting.html

It looks like it is very pedantic about the input it can receive.

Sincerely,

Joshua D. Drake




 
-- 

  === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate




---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] effective_cache_size vs units

2006-12-18 Thread Magnus Hagander
Peter Eisentraut wrote:
 Magnus Hagander wrote:
 Is there any special reason why I can't use Mb and Gb and such
 for effective_cache_size, the way I can for say shared_buffers?
 
 You can't use Mb or Gb for shared_buffers either, because those are 
 not accepted units.
 

Oh, you mean MB vs Mb. Man, it had to be that simple :)

Sorry about the noise.

//Magnus

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: [HACKERS] effective_cache_size vs units

2006-12-18 Thread Tom Lane
Magnus Hagander [EMAIL PROTECTED] writes:
 Oh, you mean MB vs Mb. Man, it had to be that simple :)

ISTM we had discussed whether guc.c should accept units strings in
a case-insensitive manner, and the forces of pedantry won the first
round.  Shall we reopen that argument?

regards, tom lane

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] effective_cache_size vs units

2006-12-18 Thread Joshua D. Drake
On Mon, 2006-12-18 at 23:46 -0500, Tom Lane wrote:
 Magnus Hagander [EMAIL PROTECTED] writes:
  Oh, you mean MB vs Mb. Man, it had to be that simple :)
 
 ISTM we had discussed whether guc.c should accept units strings in
 a case-insensitive manner, and the forces of pedantry won the first
 round.  Shall we reopen that argument?

I don't think that anyone is going to think, oh I am using 1000 Mega Bit
of ram. Mb == MB in this case. That being said, it is documented and I
don't know that it makes that much difference as long as the
documentation is clear.

Hmm perhaps perhaps a quick statement to the effect of what is legal in
the postgresql.conf? E.g;

#
# When setting memory parameters you may used a shortened sytanx e.g.,
# 1024MB or 1GB is 1 Gigabyte of ram. Note that MB/GB is capitalized.
#


Sincerely,

Joshua D. Drake

 
   regards, tom lane
 
 ---(end of broadcast)---
 TIP 5: don't forget to increase your free space map settings
 
-- 

  === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate




---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly