Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 2B995B5DC17 for ; Tue, 20 Sep 2011 22:00:50 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 61364-02 for ; Wed, 21 Sep 2011 01:00:36 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0-rc2 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id 6607AB5DC3F for ; Tue, 20 Sep 2011 22:00:36 -0300 (ADT) 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 p8L10WJ1010688; Tue, 20 Sep 2011 21:00:32 -0400 (EDT) To: Andy Lester cc: Craig Ringer , Royce Ausburn , pgsql-performance Subject: Re: Prepared statements and suboptimal plans In-reply-to: <7B0A863F-F304-4057-807B-9B2E6137E107@petdance.com> References: <4E792417.5080205@ringerc.id.au> <9289.1316565395@sss.pgh.pa.us> <7B0A863F-F304-4057-807B-9B2E6137E107@petdance.com> Comments: In-reply-to Andy Lester message dated "Tue, 20 Sep 2011 19:42:41 -0500" Date: Tue, 20 Sep 2011 21:00:32 -0400 Message-ID: <10687.1316566832@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.404 tagged_above=-10 required=5 tests=BAYES_00=-1.9, RP_MATCHES_RCVD=-0.504 X-Spam-Level: X-Archive-Number: 201109/299 X-Sequence-Number: 45075 Andy Lester writes: > On Sep 20, 2011, at 7:36 PM, Tom Lane wrote: >> 9.2, sorry, not 9.1. We could use some motivated people testing that >> aspect of GIT HEAD, though, since I doubt the policy for when to re-plan >> is quite ideal yet. > Is motivation and a box enough? I have motivation, but not knowledge of internals enough to drive testing myself. Well, you probably don't need much internals knowledge as long as you can read a little C. The crux of what I'm worried about is choose_custom_plan() in src/backend/utils/cache/plancache.c, which is really pretty simple: decide whether to use a custom (parameter-aware) plan or a generic (not-parameter-aware) plan. You might want to shove some elog() calls in there for tracing purposes so that you can log what it did, but then it's just a matter of throwing real-world workloads at it and seeing if it makes good decisions. regards, tom lane