Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 822F964FD85 for ; Tue, 30 Dec 2008 19:02:38 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 09091-07 for ; Tue, 30 Dec 2008 19:02:35 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id D28F26501BE for ; Tue, 30 Dec 2008 19:02:34 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id mBUN2Uu2002797; Tue, 30 Dec 2008 18:02:30 -0500 (EST) To: Scott Carey cc: bricklen , Scott Marlowe , Merlin Moncure , "pgsql-performance@postgresql.org" Subject: Re: Poor plan choice in prepared statement In-reply-to: References: <33b743250812301059u31ce82faw3d72a38280b37402@mail.gmail.com> , <33b743250812301214k7a0ec4fby614d693ec7915d3@mail.gmail.com> Comments: In-reply-to Scott Carey message dated "Tue, 30 Dec 2008 13:09:24 -0800" Date: Tue, 30 Dec 2008 18:02:29 -0500 Message-ID: <2796.1230678149@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200812/237 X-Sequence-Number: 32273 Scott Carey writes: > I have also had a case where one query would take a couple hundred ms to parse, but was fairly fast to plan and execute (1/3 the parse cost) -- yet another case where a prepared statement that re-plans each execution would be helpful. At least you can prevent SQL injection and cut the parse cost. Its not all about the cost of planning the query. The point of a prepared statement IMHO is to do the planning only once. There's necessarily a tradeoff between that and having a plan that's perfectly adapted to specific parameter values. Reasonable client-side APIs should provide the option to use out-of-line parameters, which is what you want to prevent SQL injection, without hard-wiring that to the orthogonal concept of statements whose plan is prepared in advance. In libpq, for instance, PQexecParams() does that. regards, tom lane