Re: pg_plan_advice

From: Andrei Lepikhov <lepihov(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alexander Lakhin <exclusion(at)gmail(dot)com>, Lukas Fittl <lukas(at)fittl(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_plan_advice
Date: 2026-04-04 21:02:37
Message-ID: 2e7bdb5d-68ba-4c65-9931-a865ab6fc3d2@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 4/4/26 20:42, Robert Haas wrote:
> On Sat, Apr 4, 2026 at 5:34 AM Andrei Lepikhov <lepihov(at)gmail(dot)com> wrote:
> By the way, I'm really glad you hit that error. That particular error
> check is there precisely to find plans that pg_plan_advice isn't able
> to understand, and it sounds like it is doing its job as intended.
> Having problems isn't great, but knowing that you have problems is a
> lot better than still having them but not knowing about it.
That’s exactly what concerns me. I see it as a potential design flaw if
the extension has to make assumptions about possible plan configurations.
I’m not sure how it works in detail, of course. However, when I designed
Postgres replanning in the past, and made similar core changes to what
you’ve done for pg_plan_advice, this kind of problem couldn’t have
happened. So, I think it’s worth questioning the current approach and
looking for other options.

--
regards, Andrei Lepikhov,
pgEdge

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2026-04-04 21:52:02 Re: TupleDescAttr bounds checks
Previous Message Daniel Gustafsson 2026-04-04 20:38:03 Unused injection point in hash agg code