Re: Costing bug in hash join logic for semi joins - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Costing bug in hash join logic for semi joins
Date
Msg-id 29925.1531584240@sss.pgh.pa.us
Whole thread Raw
In response to Re: Costing bug in hash join logic for semi joins  (David Rowley <david.rowley@2ndquadrant.com>)
List pgsql-hackers
David Rowley <david.rowley@2ndquadrant.com> writes:
> On 10 July 2018 at 11:44, RK <korlapati@gmail.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof?
Next
From: Andrey Borodin
Date:
Subject: Re: GiST VACUUM