Received: from magus.postgresql.org ([87.238.57.229]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TVn4h-0007Gh-Ik for pgsql-performance@postgresql.org; Tue, 06 Nov 2012 17:36:31 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TVn4f-0006G7-PD for pgsql-performance@postgresql.org; Tue, 06 Nov 2012 17:36:31 +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 qA6HaRr3015782; Tue, 6 Nov 2012 12:36:28 -0500 (EST) From: Tom Lane To: Merlin Moncure cc: Rodrigo Rosenfeld Rosas , pgsql-performance@postgresql.org Subject: Re: Query completed in < 1s in PG 9.1 and ~ 700s in PG 9.2 In-reply-to: References: <509944DE.6020400@gmail.com> Comments: In-reply-to Merlin Moncure message dated "Tue, 06 Nov 2012 11:22:12 -0600" Date: Tue, 06 Nov 2012 12:36:27 -0500 Message-ID: <15781.1352223387@sss.pgh.pa.us> X-Pg-Spam-Score: -2.3 (--) X-Archive-Number: 201211/59 X-Sequence-Number: 48425 Merlin Moncure writes: > Problem could also be no statistics (run ANALYZE to test) or some > other configuration problem (like index locale), or a bona fide > regression. I'm wondering about join_collapse_limit in particular --- if that wasn't cranked up in the 9.1 installation, it would be pure luck if you got a good query plan for an example like this. Maybe that and/or other parameter settings didn't get transposed to the 9.2 installation. regards, tom lane