Received: from localhost (unknown [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id 48BA59FB4B5 for ; Wed, 10 Oct 2007 12:01:10 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024) with ESMTP id 96881-03 for ; Wed, 10 Oct 2007 12:00:44 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from dalibo-free-72.custom.lost-oasis.net (unknown [212.85.154.72]) by postgresql.org (Postfix) with ESMTP id 7A1129F931A for ; Wed, 10 Oct 2007 12:00:49 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by dalibo-free-72.custom.lost-oasis.net (Postfix) with ESMTP id C9087578072; Wed, 10 Oct 2007 17:00:47 +0200 (CEST) Received: from dalibo-free-72.custom.lost-oasis.net ([127.0.0.1]) by localhost (pyrrha.dalibo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TZQHFdWkwIb; Wed, 10 Oct 2007 17:00:47 +0200 (CEST) Received: by dalibo-free-72.custom.lost-oasis.net (Postfix, from userid 1011) id AE430578076; Wed, 10 Oct 2007 17:00:47 +0200 (CEST) Received: from [192.168.0.12] (lan31-6-82-238-146-117.fbx.proxad.net [82.238.146.117]) by dalibo-free-72.custom.lost-oasis.net (Postfix) with ESMTP id 6566D578072; Wed, 10 Oct 2007 17:00:43 +0200 (CEST) Message-ID: <470CE918.4060608@dalibo.com> Date: Wed, 10 Oct 2007 17:00:40 +0200 From: =?ISO-8859-1?Q?C=E9dric_Villemain?= User-Agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070828) MIME-Version: 1.0 To: theo@flame.co.za CC: pgsql-performance@postgresql.org Subject: Re: Performance problems with prepared statements References: <1192027540.2495.3.camel@localhost.localdomain> In-Reply-To: <1192027540.2495.3.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200710/97 X-Sequence-Number: 27119 Theo Kramer a écrit : > Hi > > I have been having some serious performance issues when using prepared > statements which I can not re-produce when using a direct statement. Let > me try to explain > > The query does an order by in descending order on several columns for > which an index exists. > > The explain output as follows > > rascal=# explain SELECT oid, * FROM calllog > WHERE calllog_mainteng = '124 ' > AND calllog_phase = 8 > AND calllog_self < 366942 > OR calllog_mainteng = '124 ' > AND calllog_phase < 8 > ORDER BY calllog_mainteng DESC, > calllog_phase DESC, > calllog_self DESC limit 25; > QUERY PLAN > --------------------------------------------------------------------------------------------------------- > Limit (cost=0.00..111.62 rows=25 width=2164) > -> Index Scan Backward using calllog_rmc_idx on calllog > (cost=0.00..53475.22 rows=11977 width=2164) > Index Cond: (calllog_mainteng = '124 '::bpchar) > Filter: (((calllog_phase = 8) AND (calllog_self < 366942)) OR > (calllog_phase < 8)) > > When running the query directly from psql it returns the required rows > in less than 100 milli-seconds. > > However, when using a prepared statement from my C application on the > above query and executing it the query duration is as follows > > SELECT oid, * FROM calllog > WHERE calllog_mainteng = '124 ' > AND calllog_phase = 8 > AND calllog_self < 366942 > OR calllog_mainteng = '124 ' > AND calllog_phase < 8 > ORDER BY calllog_mainteng DESC, > calllog_phase DESC, > calllog_self DESC limit 25 > Row[s] = 25, Duration = 435409.474 ms > > The index as per the explain is defined as follows > > "calllog_rmc_idx" UNIQUE, btree (calllog_mainteng, calllog_phase, > calllog_self) > > VACUUM and all those good things done > > Version of PostgreSQL 8.1 and 8.2 > > enable_seqscan = off > enable_sort = off > > Any advice/suggestions/thoughts much appreciated > Reading the manual, you can learn that prepared statement can (not) follow the same plan as direct query: the plan is make before pg know the value of the variable. See 'Notes' http://www.postgresql.org/docs/8.2/interactive/sql-prepare.html