David Rowley <david.rowley@2ndquadrant.com> writes:
> On 7 April 2017 at 11:47, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> What I'm on about is that you can't do the early advance to the
>> next outer tuple unless you're sure that all the quals that were
>> relevant to the uniqueness proof have been checked for the current
>> inner tuple. That affects all three join types not only merge.
> Well, look at the join code and you'll see this only happens after the
> joinqual is evaulated. I didn't make a special effort here. I just
> borrowed the location that JOIN_SEMI was already using.
Right, and that's exactly the point: some of the conditions you're
depending on might have ended up in the otherqual not the joinqual.
We'd discussed rearranging the executor logic enough to deal with
such situations and agreed that it seemed too messy; but that means
that the optimization needs to take care not to use otherqual
(ie pushed-down) conditions in the uniqueness proofs.
> Oh yeah. I get it, but that's why we ignore !can_join clauses
can_join seems to me to be not particularly relevant ... there's
nothing that prevents that from getting set for pushed-down clauses.
It's possible that the case I'm worried about is unreachable in
practice because all the conditions that could be of interest would
be strict and therefore would have forced join strength reduction.
But I'm not comfortable with assuming that.
regards, tom lane
