Re: Costing bug in hash join logic for semi joins

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

In response to

Browse pgsql-hackers by date

  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?