X-Original-To: pgsql-advocacy-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [64.117.224.193]) by svr1.postgresql.org (Postfix) with ESMTP id 1D72B30F0D8; Mon, 23 Jun 2003 09:22:56 +0000 (GMT) Received: from svr1.postgresql.org ([64.117.224.193]) by localhost (svr1.postgresql.org [64.117.224.193]) (amavisd-new, port 10024) with ESMTP id 17106-06; Mon, 23 Jun 2003 06:22:45 -0300 (ADT) Received: from mailhost3.tudelft.nl (mailhost3.tudelft.nl [130.161.180.83]) by svr1.postgresql.org (Postfix) with ESMTP id 4D3E730F582; Mon, 23 Jun 2003 06:22:45 -0300 (ADT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by rav.antivirus (Postfix) with SMTP id 70EC5424; Mon, 23 Jun 2003 11:22:44 +0200 (MEST) Received: from listserv.tudelft.nl (listserv.tudelft.nl [130.161.180.33]) by mailhost3.tudelft.nl (Postfix) with ESMTP id 687B6420; Mon, 23 Jun 2003 11:22:44 +0200 (MEST) Received: from acm (x193056-2.shuis-s.tudelft.nl [145.94.193.58]) by listserv.tudelft.nl (8.12.8p1/8.12.8) with ESMTP id h5N9LODb021647; Mon, 23 Jun 2003 11:22:44 +0200 (MEST) From: "Arjen van der Meijden" To: "'Sean Chittenden'" , Cc: "'\"Advocacy PostgreSQL\"'" , "'PostgreSQL-general'" Subject: Re: [GENERAL] interesting PHP/MySQL thread Date: Mon, 23 Jun 2003 11:21:25 +0200 Message-ID: <000a01c33968$ff7956b0$3ac15e91@acm> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <20030623030702.GM97131@perrin.int.nxad.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Archive-Number: 200306/182 X-Sequence-Number: 1394 > 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