> I know it took me a while to convince the CIO on the project I'm working > on that PostgreSQL was an improvement over MySQL. He's slowly coming > around as I start to show him what I am doing with the much richer > PostgreSQL feature set, but the performance of 7.3 compared to MySQL is > likely to remain a bit of a sticking point, because some queries are > taking 2-3 times as long on the same platform with the same data. > > If the data entry folks, who are probably about to get a look at a portion > of the application that is still using the MySQL engine, get used to the > search times there, when we switch the whole thing over to PostgreSQL we > may get complaints if searches that used to take 3-4 seconds are now > taking 10-12 seconds. (Have others noticed that 7 seconds seems to be > a threshold point for users reacting to query times?)
Whoa, something's not right. Could you please send along an EXPLAIN ANALYZE after doing a VACUUM ANALYZE of your query that's taking 3-4x longer? Something smells very strange here because my experience has been quite the opposite... I can understand 0.05ms longer per connection in setup overhead (fork() vs new thread) , but this seems like way too much... I wonder if you couldn't benefit from the use of a cursor if you're returning a large dataset. -sc http://developer.postgresql.org/docs/postgres/sql-declare.html http://developer.postgresql.org/docs/postgres/sql-fetch.html http://developer.postgresql.org/docs/postgres/sql-close.html -- Sean Chittenden ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
