Received: from makus.postgresql.org ([98.129.198.125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TSURU-0004ll-K7 for pgsql-performance@postgresql.org; Sun, 28 Oct 2012 15:06:24 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TSURS-00065M-TP for pgsql-performance@postgresql.org; Sun, 28 Oct 2012 15:06:23 +0000 Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.5/8.14.5) with ESMTP id q9SF6Ljb012201; Sun, 28 Oct 2012 11:06:21 -0400 (EDT) From: Tom Lane To: Daniel Burbridge cc: "pgsql-performance@postgresql.org" Subject: Re: Prepared statements slow in 9.2 still (bad query plan) In-reply-to: References: Comments: In-reply-to Daniel Burbridge message dated "Tue, 23 Oct 2012 15:42:10 -0000" Date: Sun, 28 Oct 2012 11:06:21 -0400 Message-ID: <12200.1351436781@sss.pgh.pa.us> X-Pg-Spam-Score: -2.5 (--) X-Archive-Number: 201210/336 X-Sequence-Number: 48295 Daniel Burbridge writes: > I have a problem with prepared statements choosing a bad query plan - I was hoping that 9.2 would have eradicated the problem :( 9.2 will only pick the "right" plan if that plan's estimated cost is a good bit cheaper than the "wrong" parameterized plan. In this case, not only is there not a lot of difference, but the difference is in the wrong direction. You need to fix that --- perhaps increasing stats targets would help? A more radical question is whether you have a well-chosen set of indexes in the first place. These two seem a bit odd, and certainly not terribly well matched to this query. regards, tom lane