I wrote:
> On further review, this did work in 8.3 when released. I think it got
> broken here:
> http://archives.postgresql.org/pgsql-committers/2008-06/msg00336.php
> because that change is preventing the "mergedvar = constant" clause from
> being seen as an equivalence, when it should be seen as one. Need to
> think about a tighter fix for the bug report that prompted that change.
The original bug report involved create_or_index_quals() pulling out
an index condition from an OR clause that appeared above an outer join
that could null the relation it wanted to indexscan. (In practice this
only arises if at least one arm of the OR has an IS NULL clause for the
target relation --- if all arms have ordinary strict index clauses
then we'd have determined during reduce_outer_joins that the outer join
could be simplified to a plain join.) I tried to fix this by altering
the meaning of the outerjoin_delayed flag slightly, but what Christian's
complaint shows is that that was a bad idea because it breaks valid
equivalence deductions.
Using outerjoin_delayed in create_or_index_quals() was always pretty
much of a crude hack anyway --- there are other cases in which it
prevents us from extracting index conditions that *would* be legitimate.
In particular, there's no reason why we should not extract an index
condition for the outer relation of the same outer join.
So I'm thinking the right thing to do is to eliminate outerjoin_delayed
from RestrictInfo in favor of storing a bitmapset that shows exactly
which relations referenced by the clause are nullable by outer joins
that are below the clause. Then create_or_index_quals() could ignore
an OR, or not, depending on whether the target relation is nullable
below the OR clause. This might permit finer-grain analysis in the
other places that currently depend on outerjoin_delayed too, though
for the moment I'll just make them check for empty-or-nonempty-set.
outerjoin_delayed should revert to its longstanding meaning within
distribute_qual_to_rels, but right at the moment there seems no
application for preserving it beyond that point. (On the other hand,
eliminating it from RestrictInfo isn't going to save any space because
of alignment considerations, so maybe we should keep it there in case
we need it in future.)
The main objection I can see to this is the expansion of RestrictInfo,
but it's a pretty large struct already and one more pointer isn't
going to make much difference.
Comments?
regards, tom lane