Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 332A7633E02 for ; Mon, 30 Mar 2009 17:02:35 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 88803-02-4 for ; Mon, 30 Mar 2009 17:02:28 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sprite.sidhe.org (75-54-192-43.uvs.wlfrct.sbcglobal.net [75.54.192.43]) by mail.postgresql.org (Postfix) with SMTP id 989C163506C for ; Mon, 30 Mar 2009 17:02:30 -0300 (ADT) Received: (qmail 24070 invoked by uid 1021); 30 Mar 2009 20:02:29 -0000 Received: from localhost (HELO www.sidhe.org) (127.0.0.1) by sprite.sidhe.org (qpsmtpd/0.33-dev) with SMTP; Mon, 30 Mar 2009 16:02:29 -0400 Received: from 199.172.169.17 (SquirrelMail authenticated user dan) by localhost with HTTP; Mon, 30 Mar 2009 16:02:28 -0400 (EDT) Message-ID: <56164.199.172.169.17.1238443348.squirrel@localhost> In-Reply-To: References: <58166.199.172.169.15.1238435452.squirrel@localhost> <603c8f070903301131p8086067ob552d09e8b21c82@mail.gmail.com> <56921.199.172.169.36.1238438533.squirrel@localhost> <57654.199.172.169.17.1238442145.squirrel@localhost> Date: Mon, 30 Mar 2009 16:02:28 -0400 (EDT) Subject: Re: Trying to track down weird query stalls From: dan@sidhe.org To: "Scott Marlowe" Cc: dan@sidhe.org,"Robert Haas" , pgsql-performance@postgresql.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.1 tagged_above=0 required=5 tests=RDNS_DYNAMIC=0.1 X-Spam-Level: X-Archive-Number: 200903/425 X-Sequence-Number: 33347 > On Mon, Mar 30, 2009 at 1:42 PM, wrote: >>> On Mon, Mar 30, 2009 at 12:42 PM,   wrote: >>>> Arguably in this case the actual query should run faster than the >>>> EXPLAIN >>>> ANALYZE version, since the cache is hot. (Though that'd only likely >>>> shave >>>> a few dozen ms off the runtime) >>> >>> Joining a lot of tables together?  Could be GEQO kicking in. >> >> Only if I get different query plans for the query depending on whether >> it's being EXPLAIN ANALYZEd or not. That seems unlikely... > > Yes, you can. In fact you often will. Not because it's being > explained or not, just because that's how GEQO works. Ouch. I did *not* know that was possible -- I assumed that the plan was deterministic and independent of explain analyze. The query has seven tables (one of them a temp table) and my geqo_threshold is set to 12. If I'm reading the docs right GEQO shouldn't kick in. -Dan