Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-bugs by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group