Michael Paquier <michael@paquier.xyz> writes:
> On Thu, Sep 05, 2019 at 07:20:14PM -0400, Alvaro Herrera wrote:
>> So does this proposal fix the problem that David was describing earlier?
>> If it does, Tom, would you like to get this finalized and pushed?
> Tom, David, we still have this patch registered as a bug fix in the CF
> app. Are you planning to look at it and potentially commit something?
I don't think we have any committable patch at the moment. The "stopgap"
patch I posted seems unacceptable in view of the counterexample David
found, while his original partial-revert patch doesn't look any better
than it did then.
It's possible we could salvage the "stopgap" patch with the idea David
mentioned,
>>> One thing we could look at would be to charge an additional
>>> cpu_tuple_cost per outer row for all joins except semi, anti and
>>> unique joins. This would account for the additional lookup for
>>> another matching row which won't be found and cause the planner to
>>> slightly favour keeping the unique rel on the inner side of the join,
>>> when everything else is equal.
which'd help break ties in the right direction. It's a bit scary to
be fixing this issue by changing the cost estimates for non-unique
joins --- that could have side-effects we don't want. But arguably,
the above is a correct refinement to the cost model, so maybe it's
okay.
Or, since I think we're out of the realm of what would be sane to
back-patch anyway, maybe it's time to take two steps back and try
to find a real, non-stopgap solution. As I said upthread, I think
the core problem here is failure to distinguish quals associated with
the uniqueness condition from additional "filter" quals that have to
be checked anyway. I wonder how hard that is to fix.
regards, tom lane