From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: allowing extensions to control planner behavior |
Date: | 2024-08-30 11:33:15 |
Message-ID: | CA+TgmoZroB2pNuQ4ewUe9drm+y5wWsFNLG_NmkPvET0PxeeHsg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Aug 29, 2024 at 6:49 PM Jeff Davis <pgsql(at)j-davis(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bertrand Drouvot | 2024-08-30 11:48:29 | Re: Add contrib/pg_logicalsnapinspect |
Previous Message | Junwang Zhao | 2024-08-30 10:18:12 | Re: why there is not VACUUM FULL CONCURRENTLY? |