Re: pg_plan_advice

On Thu, Feb 19, 2026 at 1:53 AM Alexandra Wang
<alexandra(dot)wang(dot)oss(at)gmail(dot)com> wrote:
> I'm about halfway through reviewing 0002 and only now finally
> understand what 0001 is doing. 0001 looks good to me.

Great!

> This took me a bit to work through. I'll send more feedback by the end
> of this week.

Yeah, it's a huge patch. Thanks for having a look through it. I look
forward to your feedback.

Here's v17. I have committed what was previously 0004 (which Richard
reviewed on another thread) so that is dropped from this version. In
addition, this version fixes the last issue that was causing failures
running test_plan_advice with pg_plan_advice.feedback_warnings=on. In
my previous email, I said that I thought the failure in question might
be caused by some undesirable coding in the self-join elimination
code, but that turned out to be incorrect. Instead, the problem was
that pga_identifier.c was using planenr_rt_fetch() in some places, and
it needs to use rt_fetch() everywhere. That's because
planner_rt_fetch() consults simple_rte_array, which both self-join
elimination and join removal can mutate, while rt_fetch() uses the
Query's rtable directly, and that never changes. Since we're trying to
create stable identifiers, "never changes" is what we want. In
addition to changing that, I also cleaned up a few XXX comments.

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