aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gistbuild.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2012-08-15 00:07:15 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2012-08-15 00:08:42 -0400
commit43ccd309cbf4e9b09ac59130c9b31a1c58a9ff2d (patch)
tree047f932960603cbfcf0eb857cf6d25e11b5b6875 /src/backend/access/gist/gistbuild.c
parentd5bcb33603a8ef1ac7779ff0e7d4550ce522673e (diff)
downloadpostgresql-43ccd309cbf4e9b09ac59130c9b31a1c58a9ff2d.tar.gz
postgresql-43ccd309cbf4e9b09ac59130c9b31a1c58a9ff2d.zip
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.
Diffstat (limited to 'src/backend/access/gist/gistbuild.c')
0 files changed, 0 insertions, 0 deletions