Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 38D4E1337B83 for ; Thu, 12 May 2011 11:51:55 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 18626-02 for ; Thu, 12 May 2011 14:51:47 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id 4B7071337A67 for ; Thu, 12 May 2011 11:51:47 -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 p4CEpgiq015687; Thu, 12 May 2011 10:51:42 -0400 (EDT) To: Josh Berkus cc: pgsql-performance@postgresql.org, Shaun Thomas Subject: Re: Postgres refusing to use >1 core In-reply-to: <4DCB346E.8070608@agliodbs.com> References: <4DC81A3F020000250003D433@gw.wicourts.gov> <4DC81D56020000250003D438@gw.wicourts.gov> <4DC8B893.3060908@postnewspapers.com.au> <4DC9E7C5.9080309@postnewspapers.com.au> <4DCAB3A1.2090507@peak6.com> <201105111953.060147@ms14.lnh.mail.rcn.net> <4DCB0802.9060505@peak6.com> <4DCB346E.8070608@agliodbs.com> Comments: In-reply-to Josh Berkus message dated "Wed, 11 May 2011 18:14:22 -0700" Date: Thu, 12 May 2011 10:51:42 -0400 Message-ID: <15686.1305211902@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201105/176 X-Sequence-Number: 43685 Josh Berkus writes: > On 5/11/11 3:04 PM, Shaun Thomas wrote: >> The original query, with our very large tables, ran for over *two hours* >> thanks to a nested loop iterating over the subquery. My replacement ran >> in roughly 30 seconds. If we were using a newer version of PG, we could >> have used a CTE. But do you get what I mean? Temp tables are a fairly >> common technique, but how would a coder know about CTEs? They're pretty >> new, even to *us*. > For that matter, it would be even better if PostgreSQL realized that a > materialize of the subquery was a better execution plan, and just did it > for you. It does. I was a bit surprised that Shaun apparently got a plan that didn't include a materialize step, because when I test a similar query here, I get: 1. a hash join, until I turn off enable_hashjoin; then 2. a merge join, until I turn off enable_mergejoin; then 3. a nestloop with materialize on the subquery scan. In 9.0 and up I can get a nestloop without materialize by also turning off enable_material, but pre-9.0 there's no such option ... regards, tom lane