Re: allowing extensions to control planner behavior - Mailing list pgsql-hackers

From Robert Haas
Subject Re: allowing extensions to control planner behavior
Date
Msg-id CA+TgmoZroB2pNuQ4ewUe9drm+y5wWsFNLG_NmkPvET0PxeeHsg@mail.gmail.com
Whole thread Raw
In response to Re: allowing extensions to control planner behavior  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: allowing extensions to control planner behavior
List pgsql-hackers
On Thu, Aug 29, 2024 at 6:49 PM Jeff Davis <pgsql@j-davis.com> wrote:
> I don't see that in the code yet, so I assume you are referring to the
> comment at [1]?

FYI, I'm hacking on a revised approach but it's not ready to show to
other people yet.

> I still like my idea to generalize the pathkey infrastructure, and
> Robert asked for other approaches to consider. It would allow us to
> hold onto multiple paths for longer, similar to pathkeys, which might
> offer some benefits or simplifications.

This is a fair point. I dislike the fact that add_path() is a thicket
of if-statements that's actually quite hard to understand and easy to
screw up when you're making modifications. But I feel like it would be
difficult to generalize the infrastructure without making it
substantially slower, which would probably cause too much of an
increase in planning time to be acceptable. So my guess is that this
is a dead end, unless there's a clever idea that I'm not seeing.

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



pgsql-hackers by date:

Previous
From: Junwang Zhao
Date:
Subject: Re: why there is not VACUUM FULL CONCURRENTLY?
Next
From: Bertrand Drouvot
Date:
Subject: Re: Add contrib/pg_logicalsnapinspect