Re: Costing bug in hash join logic for semi joins
От | Tom Lane |
---|---|
Тема | Re: Costing bug in hash join logic for semi joins |
Дата | |
Msg-id | 29925.1531584240@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Costing bug in hash join logic for semi joins (David Rowley <david.rowley@2ndquadrant.com>) |
Список | 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 по дате отправления: