From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
Cc: | RK <korlapati(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Costing bug in hash join logic for semi joins |
Date: | 2018-07-14 16:04:00 |
Message-ID: | 29925.1531584240@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> writes:
> On 10 July 2018 at 11:44, RK <korlapati(at)gmail(dot)com> wrote:
>> There is a costing bug in hash join logic seems to have been introduced by
>> the patch related to inner_unique enhancements(commit:
>> 9c7f5229ad68d7e0e4dd149e3f80257893e404d4).
> Thanks for the analysis and the report. I agree the code is wrong.
> Looks simple enough just to handle the semi and unique joins in the
> else clause and make the if handle the ANTI join.
Looks good to me too. But you should have done "make check-world".
It turns out that this causes a couple of plan choices in contrib tests
to flip back to what they were before 9c7f5229a. We hadn't questioned
those changes closely at the time, which may have been unduly sloppy.
> I've done that in the attached. Also on reading the comment above, it
> looks slightly incorrect. To me, it looks like it's applying a
> twentieth of the cost and not a tenth as the comment claims. I
> couldn't resist updating that too.
No, it's correct as-is. There's a factor of 0.5 in the corresponding
run_cost calculations for the other two cases, so using 0.05 here is
one-tenth as much.
Pushed with those adjustments.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrey Borodin | 2018-07-14 17:43:26 | Re: GiST VACUUM |
Previous Message | Tom Lane | 2018-07-14 14:29:23 | Re: CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof? |