Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 44380633B85 for ; Mon, 30 Mar 2009 16:47:23 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 18453-06 for ; Mon, 30 Mar 2009 16:47:20 -0300 (ADT) X-Greylist: delayed 00:09:12.981433 by SQLgrey-1.7.6 Received: from mail-ew0-f167.google.com (mail-ew0-f167.google.com [209.85.219.167]) by mail.postgresql.org (Postfix) with ESMTP id C0D49633B13 for ; Mon, 30 Mar 2009 16:47:19 -0300 (ADT) Received: by ewy11 with SMTP id 11so3642630ewy.19 for ; Mon, 30 Mar 2009 12:47:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mN81aQ9rgYjXxgdTvc2nW5QC9pKsO5BnVpzJTwQnfNQ=; b=JW+xCaTr0Ww66wVgRE4+Zxq17rrb+6j4JQw933gWh+DhezGH4mLOqRBTO8tUUXN2B0 ybqV0YTLPbY/1yHLuqdMzto/woM6hHPn+sI8DBKAcGAx/lp0wcKd0xjrKEucRCuwaS15 Ti8C/EZPlsknASQ8TfgNl33UEr1sCqVV+XapI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DzzF3AGspXJS7Rfvm9MoXe8bkf8z8boUfJGjcxAfzWLmjQwV6YUp58KarTSZ7W1jCa EV+kmKX9yMEfP1C1SgNha8Q9YrkItgR/cwHj65ZfxCWPyGTgf26vPXDSSvRefS6YG8AC FhruX8B43BS55H/RWy59zckdHzyeedVcjvfRI= MIME-Version: 1.0 Received: by 10.210.105.8 with SMTP id d8mr4365666ebc.48.1238442437841; Mon, 30 Mar 2009 12:47:17 -0700 (PDT) In-Reply-To: <57654.199.172.169.17.1238442145.squirrel@localhost> 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 13:47:17 -0600 Message-ID: Subject: Re: Trying to track down weird query stalls From: Scott Marlowe To: dan@sidhe.org Cc: Robert Haas , pgsql-performance@postgresql.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200903/424 X-Sequence-Number: 33346 On Mon, Mar 30, 2009 at 1:42 PM, wrote: >> On Mon, Mar 30, 2009 at 12:42 PM, =A0 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? =A0Could 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.