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

pgsql: Resurrect the "last ditch" code path injoin_search_one_level().

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Resurrect the "last ditch" code path injoin_search_one_level().
Date: 2012-08-15 04:08:58
Message-ID: (view raw, whole thread or download thread mbox)
Lists: 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.



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

pgsql-committers by date

Next:From: Tom LaneDate: 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 MomjianDate: 2012-08-15 03:25:33
Subject: pgsql: Add more limited large object trigger example.

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