From: Scott Marlowe <scott.marlowe@gmail.com>
To: dan@sidhe.org
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Trying to track down weird query stalls
Date: Mon, 30 Mar 2009 13:47:17 -0600
Message-ID: <dcc563d10903301247t58bef7cbsd0b6d3bbd1a5e046@mail.gmail.com> (raw)
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>
<dcc563d10903301238u135d82bpf498c2d40ac31977@mail.gmail.com>
<57654.199.172.169.17.1238442145.squirrel@localhost>
On Mon, Mar 30, 2009 at 1:42 PM, <dan@sidhe.org> wrote:
>> On Mon, Mar 30, 2009 at 12:42 PM, <dan@sidhe.org> 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.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: scott.marlowe@gmail.com, dan@sidhe.org, robertmhaas@gmail.com
Subject: Re: Trying to track down weird query stalls
In-Reply-To: <dcc563d10903301247t58bef7cbsd0b6d3bbd1a5e046@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox