Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower - Mailing list pgsql-bugs

From David Rowley
Subject Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower
Date
Msg-id CAApHDvpsgqopTiEFv5HoMkevAmxKapwxm6188U=KthZWWfAQ=w@mail.gmail.com
Whole thread Raw
In response to Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower  (Richard Guo <guofenglinux@gmail.com>)
Responses Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower
List pgsql-bugs
On Thu, 28 Sept 2023 at 16:22, Richard Guo <guofenglinux@gmail.com> wrote:
> It seems that optimizing IS NULL quals is more complex than optimizing
> IS NOT NULL quals.  I also wonder if it's worth the trouble to optimize
> IS NULL quals.

I'm happy to reduce the scope of this patch. As for what to cut, I
think if we're doing a subset then we should try to do that subset in
a way that best leaves things open for phase 2 at some later date.

In my view, it would be less surprising that this works for base quals
and not join quals than if it worked with "Var IS NOT NULL" but not
"Var IS NULL".  I'm unsure if my view is clouded by the fact that I
don't have a clear picture in my head on how this should work for join
quals, however.

Would it be surprising if this didn't work for join quals?  My
thoughts are probably not any more so than the fact that extended
statistics only work for base quals and not join quals, but I'm sure
other people will have different views on that. I don't feel like we
should end up with exactly nothing committed from this patch solely
due to scope creep.

David



pgsql-bugs by date:

Previous
From: Michael Paquier
Date:
Subject: Re: BUG #18135: Incorrect memory access occurs when attaching a partition with an index
Next
From: Alexander Lakhin
Date:
Subject: Re: BUG #18135: Incorrect memory access occurs when attaching a partition with an index