Resurrect the "last ditch" code path in join_search_one_level().
This essentially reverts commit e54b10a62db2991235fe800c629baef4531a6d67,
in which I'd decided that the "last ditch" join logic was useless. The
folly of that is now exposed by a report from Pavel Stehule: although the
function should always find at least one join in a self-contained join
problem, it can still fail to do so in a sub-problem created by artificial
from_collapse_limit or join_collapse_limit constraints. Adjust the
comments to describe this, and simplify the code a bit to match the new
coding of the earlier loop in the function.
I'm not terribly happy about this: I still subscribe to the opinion stated
in the previous commit message that the "last ditch" code can obscure logic
bugs elsewhere. But the alternative seems to be to complicate the earlier
tests for does-this-relation-have-a-join-clause to the point where they can
tell whether the join clauses link outside the current join sub-problem.
And that looks messy, slow, and possibly a source of bugs in itself.
In any case, now is not the time to be inserting experimental code into
9.2, so let's just go back to the time-tested solution.
src/backend/optimizer/path/joinrels.c | 71 ++++++++++++++++++++++++++-------
1 files changed, 56 insertions(+), 15 deletions(-)
pgsql-committers by date
|Next:||From: Tom Lane||Date: 2012-08-15 04:15:22|
|Subject: Re: [COMMITTERS] pgsql: Revert "commit_delay" change; just add comment that we don't hav|
|Previous:||From: Bruce Momjian||Date: 2012-08-15 03:25:33|
|Subject: pgsql: Add more limited large object trigger example.|