|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Michael Paquier <michael(at)paquier(dot)xyz>|
|Cc:||Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Marko Tiikkaja <marko(at)joh(dot)to>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: BUG #15383: Join Filter cost estimation problem in 10.5|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Michael Paquier <michael(at)paquier(dot)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
>>> 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
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
|Next Message||Thomas Munro||2019-12-01 22:50:00||Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch|
|Previous Message||Tom Lane||2019-11-30 16:00:32||Re: Strange query planner behavior|