Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 78E406345F6; Mon, 9 Mar 2009 14:04:27 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 49095-01; Mon, 9 Mar 2009 14:04:23 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-bw0-f170.google.com (mail-bw0-f170.google.com [209.85.218.170]) by mail.postgresql.org (Postfix) with ESMTP id 96414634598; Mon, 9 Mar 2009 14:04:24 -0300 (ADT) Received: by bwz18 with SMTP id 18so1812983bwz.19 for ; Mon, 09 Mar 2009 10:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ru7d1ctuV1eXkhb28Vf1xGvzJkhvsIe8+d4mt91cACE=; b=QSorsANW93B+TGpK3XzxewIIZPmnp0MgjPxUd3eVEkKjbBty1ZjuQgL3r9S0+J56qG ts6XUslftaDrBNYMVW4lc8RtdN2fNPW3jO/8/cFMDkKupvcPvx+lganj6pQYNWqPKt72 TvM20AcHGhikjM7FPh8AT0p6D+qeGDb+XA9CM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=kd+bWvN9ogfnYB9pH7gwqlhjSpOCzb7VAYNx+OyWP3VXmJwUk5x49jPiWIBZPn74g0 WBfRfYrZt5tR23Q7Q4xwcaUkA46wX0S+xo7qy4Nck4AvdNthPCKXwWQl4ZLgBfoS9cr3 BU1sV8BuH77f2l8PWjpNYs9GySBx0rsJqInZ4= MIME-Version: 1.0 Received: by 10.223.107.68 with SMTP id a4mr4639249fap.104.1236618263151; Mon, 09 Mar 2009 10:04:23 -0700 (PDT) In-Reply-To: <87fxhmmygj.fsf@meuh.mnc.lan> References: <49B51B60.6030600@megafon.hr> <27649.1236616294@sss.pgh.pa.us> <87fxhmmygj.fsf@meuh.mnc.lan> Date: Mon, 9 Mar 2009 18:04:23 +0100 Message-ID: <1d4e0c10903091004m758d7ea2s91e33631be81215a@mail.gmail.com> Subject: Re: [PERFORM] Query much slower when run from postgres function From: Guillaume Smet To: Guillaume Cottenceau Cc: Mario Splivalo , pgsql-performance@postgresql.org, pgsql-jdbc@postgresql.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: 200903/29 X-Sequence-Number: 19359 On Mon, Mar 9, 2009 at 5:51 PM, Guillaume Cottenceau wrote: > Until it's possible to specifically tell the JDBC driver (and/or > PG?) to not plan once for all runs (or is there something better > to think of?), or the whole thing would be more clever (off the > top of my head, PG could try to replan with the first actual > values - or first xx actual values - and if the plan is > different, then flag that prepared statement for replanning each > time if the overall time estimate is different enough), I've > opted to tell the JDBC driver to use the protocol version 2, as > prepared statements were not so much prepared back then (IIRC > parameter interpolation is performed in driver and the whole SQL > query is passed each time, parsed, and planned) using > protocolVersion=2 in the JDBC URL. So far it worked very well for > us. Unnamed prepared statements are planned after binding the values, starting with 8.3, or more precisely starting with 8.3.2 as early 8.3 versions were partially broken on this behalf. It's not always possible to use protocol version 2 as it's quite limited (especially considering the exceptions returned). -- Guillaume