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 7776A30F469; Mon, 23 Jun 2003 03:07:14 +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 51682-06; Mon, 23 Jun 2003 00:07:04 -0300 (ADT) Received: from perrin.int.nxad.com (internal.ext.nxad.com [69.1.70.251]) by svr1.postgresql.org (Postfix) with ESMTP id D712A30D174; Mon, 23 Jun 2003 00:07:03 -0300 (ADT) Received: by perrin.int.nxad.com (Postfix, from userid 1001) id 79DA82105E; Sun, 22 Jun 2003 20:07:02 -0700 (PDT) Date: Sun, 22 Jun 2003 20:07:02 -0700 From: Sean Chittenden To: nolan@celery.tssi.com Cc: Jan Wieck , Bruce Momjian , Josh Berkus , Joe Conway , "\"Advocacy PostgreSQL\"" , PostgreSQL-general Subject: Re: [GENERAL] interesting PHP/MySQL thread Message-ID: <20030623030702.GM97131@perrin.int.nxad.com> References: <3EF655E7.9070709@Yahoo.com> <20030623025439.28324.qmail@celery.tssi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030623025439.28324.qmail@celery.tssi.com> X-PGP-Key: finger seanc@FreeBSD.org X-PGP-Fingerprint: 3849 3760 1AFE 7B17 11A0 83A6 DD99 E31F BC84 B341 X-Web-Homepage: http://sean.chittenden.org/ User-Agent: Mutt/1.5.4i X-Archive-Number: 200306/161 X-Sequence-Number: 1373 > 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