> Sean Chittenden wrote:
>
> 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
>
Apparently it's hard to believe, but yes that's quite possible. And if
your query takes only 0.01ms than the 0.05 is quite a difference ;)
I've tested and compared both mysql and postgresql a few times and saw
both databases beat each other largely on performance.
If the query was "more complicated", postgresql is probably the winner.
But if it's a simple query (for instance a index-lookup) than mysql
beats postgres, yes 3-4x faster is very possible in such a case.
At least from my experience, but then again I'm not _that_ well educated
on the performance-tuning-options of postgres, I just improve the
sortmem and sharedmem and hope that's all to it. (actually, I left mysql
in more or less the default settings...)
There isn't any real documentation on the performance gains and losses
on all those options anyway, is there? So don't expect people to have
the best tuned database there is, that's relatively impossible if you
don't read this mailinglist 24/7 :)
Regards,
Arjen
