Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower

From: Richard Guo <guofenglinux(at)gmail(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Andrei Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, william(dot)duclot(at)gmail(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower
Date: 2023-12-01 10:07:03
Message-ID: CAMbWs49xo3oCnL+3ouzer7UZsuso7e=z8TxU2J0ZSqc=YfFK6A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On Wed, Nov 29, 2023 at 8:48 AM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:

> I rebased your v7 patch on top of 930d2b442 and updated the expected
> results of some new regression tests which now have their NullTest
> clauses removed.

Thanks for your rebase.

> On looking deeper, I see you're overwriting the rinfo_serial of the
> const-false RestrictInfo with the one from the original RestrictInfo.
> If that's the correct thing to do then the following comment would
> need to be updated to mention this exception of why the rinfo_serial
> isn't unique.

Right, that's what we need to do.

> Looking at the tests, I see:
>
> select * from pred_tab t1 left join pred_tab t2 on true left join
> pred_tab t3 on t2.a is null;
>
> I'm wondering if you can come up with a better test for this? I don't
> quite see any reason why varnullingrels can't be empty for t2.a in the
> join qual as the "ON true" join condition between t1 and t2 means that
> there shouldn't ever be any NULL t2.a rows. My thoughts are that if
> we improve how varnullingrels are set in the future then this test
> will be broken.
>
> Also, I also like to write exactly what each test is testing so that
> it's easier in the future to maintain the expected results. It's
> often tricky when making planner changes to know if some planner
> changes makes a test completely useless or if the expected results
> just need to be updated. If someone changes varnullingrels to be
> empty for this case, then if they accept the actual results as
> expected results then the test becomes useless. I tend to do this
> with comments in the .sql file along the lines of "-- Ensure ..."
>
> I also would rather see the SQLs in the test wrap their lines before
> each join and the keywords to be upper case.

Thanks for the suggestions on the tests. I had a go at improving the
test queries and their comments.

BTW, I changed the subject of this patch to 'Reduce NullTest quals to
constant TRUE or FALSE', which seems more accurate to me, because this
patch also reduces IS NULL clauses to constant-FALSE when applicable, in
addition to ignoring redundant NOT NULL clauses.

Thanks
Richard

Attachment Content-Type Size
v9-0001-Reduce-NullTest-quals-to-constant-TRUE-or-FALSE.patch application/octet-stream 34.7 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Alvaro Herrera 2023-12-01 14:20:28 Re: BUG #17948: libpq seems to misbehave in a pipelining corner case
Previous Message PG Bug reporting form 2023-12-01 03:15:55 BUG #18220: drop database in anytime

Browse pgsql-hackers by date

  From Date Subject
Next Message Drouvot, Bertrand 2023-12-01 10:13:52 Re: Synchronizing slots from primary to standby
Previous Message Amit Kapila 2023-12-01 09:57:33 Re: Is this a problem in GenericXLogFinish()?