Re: BUG #15383: Join Filter cost estimation problem in 10.5

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
Date: 2019-11-30 17:32:38
Message-ID: 30791.1575135158@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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
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

In response to

Browse pgsql-bugs by date

  From Date Subject
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