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

From Richard Guo
Subject Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower
Date
Msg-id CAMbWs4-cWwe0whACTuKTLT+4jNcSJ+RLEcSp4us1vBAt0k7GAA@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  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower
Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower
List pgsql-bugs

On Mon, Jul 10, 2023 at 10:14 AM David Rowley <dgrowleyml@gmail.com> wrote:
On Fri, 7 Jul 2023 at 19:03, Richard Guo <guofenglinux@gmail.com> wrote:
> Attached is what I have in mind.  The patch extends the logic from two
> points.
>
> * it also checks OR clauses to see if it is always true.
>
> * it also checks for join clauses by additionally testing if the nulling
> bitmap is empty.

Do you mind writing some regression tests for this?

I don't really see an existing test file that would suit, maybe it's
worth adding something like predicate.sql

Here is v3 patch with regression tests.  I add the new test into the
group where stats test is in, but I'm not sure if this is the right
place.

Thanks
Richard
Attachment

pgsql-bugs by date:

Previous
From: David Rowley
Date:
Subject: Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower
Next
From: Vamshikrishna T
Date:
Subject: Re: BUG #18009: Postgres Recovery not happening