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 pgsql-hackers |
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
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 |
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Dilger | 2019-11-30 18:04:07 | Re: Make autovacuum sort tables in descending order of xid_age |
Previous Message | Tom Lane | 2019-11-30 15:21:01 | Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch |