> 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
