Re: [pgsql-advocacy] interesting PHP/MySQL thread
От | Arjen van der Meijden |
---|---|
Тема | Re: [pgsql-advocacy] interesting PHP/MySQL thread |
Дата | |
Msg-id | 000a01c33968$ff7956b0$3ac15e91@acm обсуждение исходный текст |
Ответ на | Re: [pgsql-advocacy] interesting PHP/MySQL thread (Sean Chittenden <sean@chittenden.org>) |
Список | pgsql-general |
> 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
В списке pgsql-general по дате отправления: