Re: pg_plan_advice - Mailing list pgsql-hackers

From Robert Haas
Subject Re: pg_plan_advice
Date
Msg-id CA+TgmoaaS8kwX6S9+x_0j9iMox6dbRQrfCzdiy48xUmF5HRmmA@mail.gmail.com
Whole thread
In response to Re: pg_plan_advice  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_plan_advice
List pgsql-hackers
On Wed, Mar 18, 2026 at 6:26 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Well, that's embarrassing: it's a copy-and-paste error. The test
> > prepares and executes pt1, then prepares and executes pt2, then
> > prepares pt3 and executes pt1, then prepares pt4 and execute p2. pt3
> > and pt4 are never used for anything. Also there's a related typo in a
> > comment. See attached.
>
> Ah ... so the observed behavior is because if pt2 does get replanned,
> that happens with a different always_store_advice_details setting
> than it used originally?

Close, but not quite. always_store_advice_details is set for the
even-numbered tests, so it's the same for pt2 and pt4. But
pg_plan_advice.advice is empty for the the first half of the file and
set for the second half of the file, so it's empty when pt2 is
prepared and contains SEQ_SCAN(ptab) when pt4 is prepared. That
accounts for the difference. avocet is actually doing the right thing,
and the rest of the buildfarm is doing the wrong thing for lack of
replanning.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Initial COPY of Logical Replication is too slow
Next
From: Tomas Vondra
Date:
Subject: Re: EXPLAIN: showing ReadStream / prefetch stats