Horton

Thread

Commits

  1. Fix confusion about havingQual vs hasHavingQual in planner.

  1. havingQual vs hasHavingQual buglets

    Tom Lane <tgl@sss.pgh.pa.us> — 2022-10-17T21:37:23Z

    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

  2. Re: havingQual vs hasHavingQual buglets

    Richard Guo <guofenglinux@gmail.com> — 2022-10-18T00:47:35Z

    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

  3. Re: havingQual vs hasHavingQual buglets

    Etsuro Fujita <etsuro.fujita@gmail.com> — 2022-10-18T09:23:49Z

    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

  4. Re: havingQual vs hasHavingQual buglets

    Tom Lane <tgl@sss.pgh.pa.us> — 2022-10-18T14:46:46Z

    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