pgsql: Resurrect the "last ditch" code path in join_search_one_level(). - Mailing list pgsql-committers

From Tom Lane
Subject pgsql: Resurrect the "last ditch" code path in join_search_one_level().
Date
Msg-id E1T1Uug-0000Qe-W1@gemulon.postgresql.org
Whole thread Raw
List pgsql-committers
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.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/eb919e8fde4333d4a627d349a1460b07fc52dd3b

Modified Files
--------------
src/backend/optimizer/path/joinrels.c |   71 ++++++++++++++++++++++++++-------
1 files changed, 56 insertions(+), 15 deletions(-)


pgsql-committers by date:

Previous
From: Bruce Momjian
Date:
Subject: pgsql: Add more limited large object trigger example.
Next
From: Tom Lane
Date:
Subject: pgsql: Resurrect the "last ditch" code path in join_search_one_level().