Re: Trying to track down weird query stalls

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: dan(at)sidhe(dot)org
Cc: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Trying to track down weird query stalls
Date: 2009-03-30 20:13:27
Message-ID: 603c8f070903301313u1a9606a3m27da187b5e376785@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Mon, Mar 30, 2009 at 4:02 PM, <dan(at)sidhe(dot)org> wrote:
>> On Mon, Mar 30, 2009 at 1:42 PM,  <dan(at)sidhe(dot)org> wrote:
>>>> On Mon, Mar 30, 2009 at 12:42 PM,  <dan(at)sidhe(dot)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.
>
> 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.

Any chance we could see the actual query? Right now I think we are
shooting in the dark.

...Robert

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message dan 2009-03-30 20:33:14 Re: Trying to track down weird query stalls
Previous Message dan 2009-03-30 20:02:28 Re: Trying to track down weird query stalls