Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id F28E91136F89 for ; Sat, 4 Aug 2012 03:26:59 -0300 (ADT) Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1SxXpA-0001gu-Jf for pgsql-performance@postgresql.org; Sat, 04 Aug 2012 06:26:58 +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 q746QgwF025290; Sat, 4 Aug 2012 02:26:42 -0400 (EDT) From: Tom Lane To: "Midge Brown" cc: pgsql-performance@postgresql.org Subject: Re: slow query, different plans In-reply-to: <9CF5A680782142D794A085320949FED4@BERNICE> References: <9CF5A680782142D794A085320949FED4@BERNICE> Comments: In-reply-to "Midge Brown" message dated "Fri, 03 Aug 2012 17:38:33 -0700" Date: Sat, 04 Aug 2012 02:26:42 -0400 Message-ID: <25289.1344061602@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201208/19 X-Sequence-Number: 47557 "Midge Brown" writes: > I'm having a problem with a query on our production server, but not on a laptop running a similar postgres version with a recent backup copy of the same table. I tried reindexing the table on the production server, but it didn't make any difference. Other queries on the same table are plenty fast. Reindexing won't help that. The problem is a bad statistical estimate; it thinks there are about 700 rows with applies2 = 256, when there's really only one. That means the "fast" plan is a lot faster than the planner gives it credit for, and conversely the "slow" plan is a lot slower than the planner is expecting. Their estimated costs end up nearly the same, which makes it a bit of a chance matter which one is picked --- but the true costs are a lot different. So you need to fix that rowcount estimate. Raising the stats target for the table might help. regards, tom lane