havingQual vs hasHavingQual buglets
I came across a couple of places in the planner that are checking
for nonempty havingQual; but since these bits run after
const-simplification of the HAVING clause, that produces the wrong
answer for a constant-true HAVING clause (which'll be folded to
empty). Correct code is to check root->hasHavingQual instead.
These mistakes only affect cost estimates, and they're sufficiently
corner cases that it'd be hard even to devise a reliable test case
showing a different plan choice. So I'm not very excited about this,
and am thinking of committing only to HEAD.
regards, tom lane
Attachments:
fix-hasHavingQual-oversights.patchtext/x-diff; charset=us-ascii; name=fix-hasHavingQual-oversights.patchDownload+3-3
On Tue, Oct 18, 2022 at 5:37 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
I came across a couple of places in the planner that are checking
for nonempty havingQual; but since these bits run after
const-simplification of the HAVING clause, that produces the wrong
answer for a constant-true HAVING clause (which'll be folded to
empty). Correct code is to check root->hasHavingQual instead.
+1. root->hasHavingQual is set before we do any expression
preprocessing. It should be the right one to check with.
Thanks
Richard
On Tue, Oct 18, 2022 at 9:47 AM Richard Guo <guofenglinux@gmail.com> wrote:
On Tue, Oct 18, 2022 at 5:37 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
I came across a couple of places in the planner that are checking
for nonempty havingQual; but since these bits run after
const-simplification of the HAVING clause, that produces the wrong
answer for a constant-true HAVING clause (which'll be folded to
empty). Correct code is to check root->hasHavingQual instead.
The postgres_fdw bits would be my oversight. :-(
+1. root->hasHavingQual is set before we do any expression
preprocessing. It should be the right one to check with.
+1 HEAD only seems reasonable.
Best regards,
Etsuro Fujita
Etsuro Fujita <etsuro.fujita@gmail.com> writes:
On Tue, Oct 18, 2022 at 9:47 AM Richard Guo <guofenglinux@gmail.com> wrote:
On Tue, Oct 18, 2022 at 5:37 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
I came across a couple of places in the planner that are checking
for nonempty havingQual; but since these bits run after
const-simplification of the HAVING clause, that produces the wrong
answer for a constant-true HAVING clause (which'll be folded to
empty). Correct code is to check root->hasHavingQual instead.
The postgres_fdw bits would be my oversight. :-(
No worries --- I think the one in set_subquery_pathlist is probably
my fault :-(
+1 HEAD only seems reasonable.
Pushed that way; thanks for looking.
regards, tom lane