Re: Endless loop in ExecNestLoop

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Philipp Reisner <philipp(dot)reisner(at)linbit(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org, sd-log(at)linbit(dot)com
Subject: Re: Endless loop in ExecNestLoop
Date: 2006-01-30 16:42:57
Message-ID: 8467.1138639377@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Philipp Reisner <philipp(dot)reisner(at)linbit(dot)com> writes:
> Version: 8.0.2

I don't think so ... neither bitmap scans nor slot_getattr exist in 8.0.

> Is this bug-report of any use so far ?

Not a lot. You need to find out what the difference is between the
cases where the query runs quickly and those where it doesn't. I'm
betting that the planner is choosing a very bad plan in the slow cases,
but there's not a lot of evidence here to show what or why.

The explain analyze output shows two levels of hash join underneath
four levels of nestloop join, whereas the stack trace looks like there
are five levels of nestloop and only one hash. So this is some evidence
that a different plan is being used in the slow cases. The stack trace
doesn't provide nearly enough info about what that plan is, though.

Do you have geqo_threshold set to less than its default value? Do you
sometimes execute the query with different sets of parameters? Either
of these might lead to changes of plan.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Philipp Reisner 2006-01-30 16:46:49 Endless loop in ExecNestLoop
Previous Message Mehul Doshi-A20614 2006-01-30 16:34:02 Shared library issue in Windows