Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Alexander Staubo
On Dec 11, 2006, at 04:35 , Tatsuo Ishii wrote: That's not the whole story. UTF-8 and other variable-width encodings don't provide a 1:1 mapping of logical characters to single bytes; in particular, combination characters opens the possibility of multiple different byte sequences mapping to the

Re: [PERFORM] Postgresql - Threshold value.

2006-12-11 Thread Rajesh Kumar Mallah
On 12/11/06, Ravindran G - TLS, Chennai. [EMAIL PROTECTED] wrote: Hello, How to get Postgresql Threshold value ?. Any commands available ?. What is meant my threshold value ? ---(end of broadcast)--- TIP 1: if posting/reading through Usenet,

Re: [PERFORM] Postgresql - Threshold value.

2006-12-11 Thread Kaloyan Iliev
Hi, try using: tmp=# show all; and tmp=# show geqo_threshold; Regards, Kaloyan Iliev Ravindran G - TLS, Chennai. wrote: Hello, How to get Postgresql Threshold value ?. Any commands available ?. Regards, Ravi DISCLAIMER The contents of this e-mail and any attachment(s) are

Re: [PERFORM] SQL_CALC_FOUND_ROWS in POSTGRESQL / Some one can

2006-12-11 Thread Ragnar
On mán, 2006-12-11 at 17:01 +1100, Chris wrote: Mark Kirkwood wrote: Chris wrote: It's the same as doing a select count(*) type query using the same clauses, but all in one query instead of two. It doesn't return any extra rows on top of the limit query so it's better than using

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Daniel van Ham Colchete
On 12/11/06, Alexander Staubo [EMAIL PROTECTED] wrote: On Dec 11, 2006, at 02:47 , Daniel van Ham Colchete wrote: I never understood what's the matter between the ASCII/ISO-8859-1/UTF8 charsets to a database. They're all simple C strings that doesn't have the zero-byte in the midlle (like

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Daniel van Ham Colchete
Hi Dave, On 12/11/06, Dave Cramer [EMAIL PROTECTED] wrote: Hi Daniel On 10-Dec-06, at 8:02 PM, Daniel van Ham Colchete wrote: Hi Gene, at my postgresql.conf, the only non-comented lines are: fsync = off This can, and will result in lost data. I know... If there is a power failure things

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Dave Cramer
On 11-Dec-06, at 5:36 AM, Daniel van Ham Colchete wrote: Hi Dave, On 12/11/06, Dave Cramer [EMAIL PROTECTED] wrote: Hi Daniel On 10-Dec-06, at 8:02 PM, Daniel van Ham Colchete wrote: Hi Gene, at my postgresql.conf, the only non-comented lines are: fsync = off This can, and will result

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Daniel van Ham Colchete
Mike, unfortunally I don't have any benchmarks right now. Doing something like this with the same machine would be a 2-day work (at least). Installing a Gentoo and putting it to run well is not a quick task (although is easy). But, trust me on this one. It's worth it. Think of this: PostgreSQL

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Daniel van Ham Colchete
How much memory does this machine have and what version of postgresql are you using? It's only a test server with 512MB RAM, I only used it to see how well would the PostgreSQL do in a ugly case. Given that optimal performance for postgresql can require up to 50% of available memory, you

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Steinar H. Gunderson
On Mon, Dec 11, 2006 at 09:05:56AM -0200, Daniel van Ham Colchete wrote: But, trust me on this one. It's worth it. You know what? I don't. Think of this: PostgreSQL and GNU LibC use a lot of complex algorithms: btree, hashes, checksums, strings functions, etc... And you have a lot of ways to

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Michael Stone
On Mon, Dec 11, 2006 at 09:05:56AM -0200, Daniel van Ham Colchete wrote: unfortunally I don't have any benchmarks right now. That's fairly normal for gentoo users pushing their compile options. Mike Stone ---(end of broadcast)--- TIP 4: Have

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Daniel van Ham Colchete
On 12/11/06, Steinar H. Gunderson [EMAIL PROTECTED] wrote: On Mon, Dec 11, 2006 at 09:05:56AM -0200, Daniel van Ham Colchete wrote: But, trust me on this one. It's worth it. You know what? I don't. So test it yourself. Think of this: PostgreSQL and GNU LibC use a lot of complex algorithms:

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Daniel van Ham Colchete
This is very very very true :-)! I just remebered one case with MySQL. When I changed the distro from Conectiva 10 (rpm-based ended brazilian distro) to Gentoo, a MySQL operation that usually took 2 minutes to run, ended in 47 seconds. This is absolutely vage. I don't have how to prove it to

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Christopher Browne
Oops! [EMAIL PROTECTED] (Daniel van Ham Colchete) was seen spray-painting on a wall: But, trust me on this one. It's worth it. No, the point of performance analysis is that you *can't* trust the people that say trust me on this one. If you haven't got a benchmark where you can demonstrate a

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Daniel van Ham Colchete
You are right Christopher. Okay. Let's solve this matter. What PostgreSQL benchmark software should I use??? I'll test PostgreSQL 8.1 on a Fedora Core 6 and on a Gentoo. I'll get the same version FC6 uses and install it at my Gentoo. I'll use the same hardware (diferent partitions to each).

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Steinar H. Gunderson
On Mon, Dec 11, 2006 at 11:09:13AM -0200, Daniel van Ham Colchete wrote: You know what? I don't. So test it yourself. You're making the claims, you're supposed to be proving them... As I said, it is an example. Take floatpoint divisions. You have plenty of ways of doing it: 387, MMX, SSE,

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Daniel van Ham Colchete
On 12/11/06, Steinar H. Gunderson [EMAIL PROTECTED] wrote: On Mon, Dec 11, 2006 at 11:09:13AM -0200, Daniel van Ham Colchete wrote: You know what? I don't. So test it yourself. You're making the claims, you're supposed to be proving them... As I said, it is an example. Take floatpoint

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Steinar H. Gunderson
On Mon, Dec 11, 2006 at 11:17:06AM -0200, Daniel van Ham Colchete wrote: I just remebered one case with MySQL. When I changed the distro from Conectiva 10 (rpm-based ended brazilian distro) to Gentoo, a MySQL operation that usually took 2 minutes to run, ended in 47 seconds. How do you know

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Steinar H. Gunderson
On Mon, Dec 11, 2006 at 11:31:48AM -0200, Daniel van Ham Colchete wrote: What PostgreSQL benchmark software should I use??? Look up the list archives; search for TPC. I'll test PostgreSQL 8.1 on a Fedora Core 6 and on a Gentoo. I'll get the same version FC6 uses and install it at my Gentoo.

Re: [PERFORM] Postgresql - Threshold value.

2006-12-11 Thread Ravindran G - TLS, Chennai.
Thank you very much for your reply. This is not working in Postgresql 8.1.4. Its throwing some error. BTW, how to fetch the total disk space that is alloted to DB in postgresql ?. Any commands available ?. Regards, Ravi -Original Message- From: Kaloyan Iliev [mailto:[EMAIL

Re: [PERFORM] Postgresql - Threshold value.

2006-12-11 Thread A. Kretschmer
am Mon, dem 11.12.2006, um 19:41:29 +0530 mailte Ravindran G - TLS, Chennai. folgendes: Thank you very much for your reply. This is not working in Postgresql 8.1.4. Its throwing some error. Which errors? test=# show geqo_threshold; geqo_threshold 12 (1 row) test=*#

Re: [PERFORM] Postgresql - Threshold value.

2006-12-11 Thread Ravindran G - TLS, Chennai.
Thanks. I am using Postgres 8.1.4 in windows 2000 and i don't get the proper response for threshold. - pg_database_size(name) - is giving the current space used by DB. But I want like Total space utilized by DB and Free space. Regards, Ravi -Original Message- From: [EMAIL

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Merlin Moncure
On 12/11/06, Daniel van Ham Colchete [EMAIL PROTECTED] wrote: But, trust me on this one. It's worth it. Think of this: PostgreSQL and GNU LibC use a lot of complex algorithms: btree, hashes, checksums, strings functions, etc... And you have a lot of ways to compile it into binary code. Now you

Re: [PERFORM] Low throughput of binary inserts from windows to linux

2006-12-11 Thread Axel Waggershauser
On 12/9/06, Tom Lane [EMAIL PROTECTED] wrote: Axel Waggershauser [EMAIL PROTECTED] writes: ... This works quite well for the following setups: client - server - linux - linux linux - windows windows - windows but pretty bad (meaning about 10 times slower) for this

Re: [PERFORM] Low throughput of binary inserts from windows to linux

2006-12-11 Thread Thomas H.
I'm out of ideas here, maybe someone could try to reproduce this behavior or could point me to the thread containing relevant information (sorry, maybe I'm just too dumb :-/) please specify how you're transfering the data from windows - linux. are you using odbc? if yes, what driver? are you

Re: [PERFORM] Low throughput of binary inserts from windows to linux

2006-12-11 Thread Axel Waggershauser
On 12/11/06, Thomas H. [EMAIL PROTECTED] wrote: I'm out of ideas here, maybe someone could try to reproduce this behavior or could point me to the thread containing relevant information (sorry, maybe I'm just too dumb :-/) please specify how you're transfering the data from windows - linux.

Re: [PERFORM] Postgresql - Threshold value.

2006-12-11 Thread Rajesh Kumar Mallah
On 12/11/06, Ravindran G - TLS, Chennai. [EMAIL PROTECTED] wrote: Thanks. I am using Postgres 8.1.4 in windows 2000 and i don't get the proper response for threshold. what is the response you get ? please be specific about the issues. also the footer that comes with your emails are not

Re: [PERFORM] Low throughput of binary inserts from windows to linux

2006-12-11 Thread Tom Lane
Axel Waggershauser [EMAIL PROTECTED] writes: On 12/9/06, Tom Lane [EMAIL PROTECTED] wrote: This has to be a network-level problem. IIRC, there are some threads in our archives discussing possibly-related performance issues seen with Windows' TCP stack. I searched the archives but found

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Chris Browne
[EMAIL PROTECTED] (Daniel van Ham Colchete) writes: You are right Christopher. Okay. Let's solve this matter. What PostgreSQL benchmark software should I use??? pgbench is one option. There's a TPC-W at pgFoundry (http://pgfoundry.org/projects/tpc-w-php/). There's the Open Source

Re: [PERFORM] Postgresql - Threshold value.

2006-12-11 Thread Tom Lane
Rajesh Kumar Mallah [EMAIL PROTECTED] writes: On 12/11/06, Ravindran G - TLS, Chennai. [EMAIL PROTECTED] wrote: I am using Postgres 8.1.4 in windows 2000 and i don't get the proper response for threshold. what is the response you get ? please be specific about the issues. Even more to the

Re: [PERFORM] Low throughput of binary inserts from windows to

2006-12-11 Thread Kevin Grittner
On Mon, Dec 11, 2006 at 8:58 AM, in message [EMAIL PROTECTED], Axel Waggershauser [EMAIL PROTECTED] wrote: I'm out of ideas here, maybe someone could try to reproduce this behavior or could point me to the thread containing relevant information No guarantees that this is the problem, but

[PERFORM] Looking for hw suggestions for high concurrency OLTP app

2006-12-11 Thread Cosimo Streppone
Hi all, I'd like to get suggestions from all you out there for a new Postgresql server that will replace an existing one. My performance analysis shows very *low* iowaits, and very high loads at times of peak system activity. The average concurrent processes number is 3/4, with peaks of 10/15.

[PERFORM] really quick multiple inserts can use COPY?

2006-12-11 Thread Jens Schipkowski
Hello! In our JAVA application we do multiple inserts to a table by data from a Hash Map. Due to poor database access implemention - done by another company (we got the job to enhance the software) - we cannot use prepared statements. (We are not allowed to change code at database access!)

Re: [PERFORM] really quick multiple inserts can use COPY?

2006-12-11 Thread Andreas Kretschmer
Jens Schipkowski [EMAIL PROTECTED] schrieb: Hello! In our JAVA application we do multiple inserts to a table by data from a Hash Map. Due to poor database access implemention - done by another company (we got the job to enhance the software) - we cannot use prepared statements. (We

Re: [PERFORM] really quick multiple inserts can use COPY?

2006-12-11 Thread Rajesh Kumar Mallah
So, my questions: Is it possible to use COPY FROM STDIN with JDBC? Should be. Its at least possible using DBI and DBD::Pg (perl) my $copy_sth = $dbh - prepare( COPY general.datamining_mailing_lists (query_id,email_key) FROM STDIN;) ; $copy_sth - execute(); while (my ($email_key ) =

Re: [PERFORM] really quick multiple inserts can use COPY?

2006-12-11 Thread Tom Lane
Jens Schipkowski [EMAIL PROTECTED] writes: Is it possible to use COPY FROM STDIN with JDBC? You should be asking the pgsql-jdbc list, not here. (I know I've seen mention of a JDBC patch to support COPY, but I dunno if it's made it into any official version.) Will it bring performance

Re: [PERFORM] really quick multiple inserts can use COPY?

2006-12-11 Thread Guillaume Cottenceau
Jens Schipkowski jens.schipkowski 'at' apus.co.at writes: Hello! In our JAVA application we do multiple inserts to a table by data from a Hash Map. Due to poor database access implemention - done by another company (we got the job to enhance the software) - we cannot use prepared

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Ron
This definitely is the correct approach. Actually, Daniel van Ham Colchete may not be as all wet as some around here think. We've had previous data that shows that pg can become CPU bound (see previous posts by Josh Berkus and others regarding CPU overhead in what should be IO bound tasks).

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Michael Stone
On Mon, Dec 11, 2006 at 12:15:51PM -0500, Ron wrote: I'd say the fairest attitude is to do everything we can to support having the proper experiments done w/o presuming the results. Who's presuming results?[1] It is fair to say that making extraordinary claims without any evidence should be

Re: [PERFORM] File Systems Compared

2006-12-11 Thread Bruno Wolff III
On Wed, Dec 06, 2006 at 08:55:14 -0800, Mark Lewis [EMAIL PROTECTED] wrote: Anyone run their RAIDs with disk caches enabled, or is this akin to having fsync off? Disk write caches are basically always akin to having fsync off. The only time a write-cache is (more or less) safe to enable

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Ron
Statements like these can not be reasonably interpreted in any manner _except_ that of presuming the results: I expect that you'll discover, if you actually do these tests, that this belief (that using arch specific compiler options lead to better performing SW) is fairly much nonsense.

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Luke Lonergan
Michael, On 12/11/06 9:31 AM, Michael Stone [EMAIL PROTECTED] wrote: [1] I will say that I have never seen a realistic benchmark of general code where the compiler flags made a statistically significant difference in the runtime. Here's one - I wrote a general purpose Computational Fluid

Re: [PERFORM] Looking for hw suggestions for high concurrency

2006-12-11 Thread Luke Lonergan
The Sun X4600 is very good for this, the V40z is actually EOL so I'd stay away from it. You can currently do 8 dual core CPUs with the X4600 and 128GB of RAM and soon you should be able to do 8 quad core CPUs and 256GB of RAM. - Luke On 12/11/06 8:26 AM, Cosimo Streppone [EMAIL PROTECTED]

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Michael Stone
On Mon, Dec 11, 2006 at 01:20:50PM -0500, Ron wrote: (The validity of the claim has nothing to do with the skills or experience of the claimant or anyone else in the discussion. Only on the evidence.) Please go back and reread the original post. I don't think the response was unwarranted.

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Michael Stone
On Mon, Dec 11, 2006 at 10:30:55AM -0800, Luke Lonergan wrote: Here's one - I wrote a general purpose Computational Fluid Dynamics analysis method used by hundreds of people to perform aircraft and propulsion systems analysis. That's kinda the opposite of what I meant by general code. I was

Re: [PERFORM] really quick multiple inserts can use COPY?

2006-12-11 Thread imad
On 12/11/06, Andreas Kretschmer [EMAIL PROTECTED] wrote: Jens Schipkowski [EMAIL PROTECTED] schrieb: Hello! In our JAVA application we do multiple inserts to a table by data from a Hash Map. Due to poor database access implemention - done by another company (we got the job to enhance the

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Merlin Moncure
On 12/11/06, Ron [EMAIL PROTECTED] wrote: Statements like these can not be reasonably interpreted in any manner _except_ that of presuming the results: I expect that you'll discover, if you actually do these tests, that this belief (that using arch specific compiler options lead to better

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Ron
At 01:47 PM 12/11/2006, Michael Stone wrote: On Mon, Dec 11, 2006 at 01:20:50PM -0500, Ron wrote: (The validity of the claim has nothing to do with the skills or experience of the claimant or anyone else in the discussion. Only on the evidence.) Please go back and reread the original post.

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Daniel van Ham Colchete
On 12/11/06, Steinar H. Gunderson [EMAIL PROTECTED] wrote: On Mon, Dec 11, 2006 at 11:17:06AM -0200, Daniel van Ham Colchete wrote: I just remebered one case with MySQL. When I changed the distro from Conectiva 10 (rpm-based ended brazilian distro) to Gentoo, a MySQL operation that usually

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Ron
At 02:28 PM 12/11/2006, Merlin Moncure wrote: also, some people posting here, not necessarily me, are authority figures. :-) merlin Noam Chomsky was one of the most influential thinkers in Linguistics to yet have lived. He was proven wrong a number of times. Even within Linguistics.

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Luke Lonergan
Michael, On 12/11/06 10:57 AM, Michael Stone [EMAIL PROTECTED] wrote: That's kinda the opposite of what I meant by general code. I was trying (perhaps poorly) to distinguish between scientific codes and other stuff (especially I/O or human interface code). Yes - choice of language has often

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Daniel van Ham Colchete
On 12/11/06, Steinar H. Gunderson [EMAIL PROTECTED] wrote: On Mon, Dec 11, 2006 at 11:31:48AM -0200, Daniel van Ham Colchete wrote: What PostgreSQL benchmark software should I use??? Look up the list archives; search for TPC. I'll test PostgreSQL 8.1 on a Fedora Core 6 and on a Gentoo. I'll

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Michael Stone
On Mon, Dec 11, 2006 at 02:51:09PM -0500, Ron wrote: Let's support getting definitive evidence. Since nobody opposed the concept of contrary evidence, I don't suppose you're fighting an uphill battle on that particular point. It's fine to get preachy about supporting intellectual curiosity,

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Daniel van Ham Colchete
On 12/11/06, Chris Browne [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Daniel van Ham Colchete) writes: You are right Christopher. Okay. Let's solve this matter. What PostgreSQL benchmark software should I use??? pgbench is one option. There's a TPC-W at pgFoundry

Re: [PERFORM] Looking for hw suggestions for high concurrency

2006-12-11 Thread Merlin Moncure
On 12/11/06, Luke Lonergan [EMAIL PROTECTED] wrote: The Sun X4600 is very good for this, the V40z is actually EOL so I'd stay away from it. also, it has no pci express slots. make sure to get pci-e slots :) You can currently do 8 dual core CPUs with the X4600 and 128GB of RAM and soon you

Re: [PERFORM] Looking for hw suggestions for high concurrency

2006-12-11 Thread Luke Lonergan
Merlin, On 12/11/06 12:19 PM, Merlin Moncure [EMAIL PROTECTED] wrote: ...and this 6 of them (wow!). the v40z was top of its class. Will K8L run on this server? No official word yet. The X4600 slipped in there quietly under the X4500 (Thumper) announcement, but it's a pretty awesome server.

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Craig A. James
Ron wrote: We are not going to get valuable contributions nor help people become more valuable to the community by flaming them into submission. Let's support getting definitive evidence. No matter who brings it to the table ;-) Thanks, Ron, for a voice of respect and reason. Since I

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Mark Kirkwood
Daniel van Ham Colchete wrote: On 12/11/06, Steinar H. Gunderson [EMAIL PROTECTED] wrote: On Mon, Dec 11, 2006 at 11:31:48AM -0200, Daniel van Ham Colchete wrote: What PostgreSQL benchmark software should I use??? Look up the list archives; search for TPC. I'll test PostgreSQL 8.1 on a

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Daniel van Ham Colchete
Hi yall, I made some preliminary tests. Before the results, I would like to make some acknowledgments: 1 - I didn't show any prove to any of the things I said until now. 2 - It really is a waste of everyone's time to say one thing when I can't prove it. But all I said, is the knowledge I have

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Luke Lonergan
Daniel, Good stuff. Can you try this with just -O3 versus -O2? - Luke On 12/11/06 2:22 PM, Daniel van Ham Colchete [EMAIL PROTECTED] wrote: Hi yall, I made some preliminary tests. Before the results, I would like to make some acknowledgments: 1 - I didn't show any prove to any of the

Re: [PERFORM] Low throughput of binary inserts from windows to linux

2006-12-11 Thread Axel Waggershauser
On 12/11/06, Tom Lane [EMAIL PROTECTED] wrote: Yeah, that's what I couldn't think of the other day. The principal report was here: http://archives.postgresql.org/pgsql-general/2005-01/msg01231.php By default, Windows XP installs the QoS Packet Scheduler service. It is not installed by

Re: [PERFORM] Low throughput of binary inserts from windows to linux

2006-12-11 Thread Tom Lane
Axel Waggershauser [EMAIL PROTECTED] writes: I tested different sizes on linux some time ago and found that 64KB was optimal. But playing with different sizes again revealed that my windows-linux problem seems to be solved if I use _any_ other (reasonable - meaning something between 4K and

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Michael Stone
On Mon, Dec 11, 2006 at 08:22:42PM -0200, Daniel van Ham Colchete wrote: TEST 01: CFLAGS=-O2 -march=i686 fsync=false tps = 734.948620 (including connections establishing) tps = 736.866642 (excluding connections establishing) [snip] TEST 03: CFLAGS=-O2 -march=pentium4 fsync=false tps =

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Christopher Browne
After a long battle with technology, [EMAIL PROTECTED] (Michael Stone), an earthling, wrote: [1] I will say that I have never seen a realistic benchmark of general code where the compiler flags made a statistically significant difference in the runtime. When we were initially trying out

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Greg Smith
On Mon, 11 Dec 2006, Michael Stone wrote: Can anyone else reproduce these results? I'm on similar hardware (2.5GHz P4, 1.5G RAM)... There are two likely candidates for why Daniel's P4 3.0GHz significantly outperforms your 2.5GHz system. 1) Most 2.5GHZ P4 processors use a 533MHz front-side

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-11 Thread Tom Lane
Greg Smith [EMAIL PROTECTED] writes: On Mon, 11 Dec 2006, Michael Stone wrote: Can anyone else reproduce these results? I'm on similar hardware (2.5GHz P4, 1.5G RAM)... There are two likely candidates for why Daniel's P4 3.0GHz significantly outperforms your 2.5GHz system. Um, you entirely

Re: [PERFORM] Low throughput of binary inserts from windows to linux

2006-12-11 Thread Florian Weimer
* Tom Lane: If you don't like that theory, another line of reasoning has to do with the fact that the maximum advertiseable window size in TCP is 65535 --- there could be some edge-case behaviors in the Windows and Linux stacks that don't play nicely together for 64K transfer sizes. Linux

Re: [PERFORM] really quick multiple inserts can use COPY?

2006-12-11 Thread Jens Schipkowski
Thanks a lot to all for your tips. Of course, I am doing all the INSERTs using a transaction. So the cost per INSERT dropped from 30 ms to 3 ms. The improvement factor matches with the hint by Brian Hurt. Sorry, I forgot to mention we are using PostgreSQL 8.1.4. Thanks for the code snippet