Re: allowing extensions to control planner behavior

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 20:04:42
Message-ID: CA+TgmoZ3wdn3NJbNLBQgiwUgiCrYiPXZCFvsDpeCO=r2e+ozBQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Aug 30, 2024 at 1:42 PM Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> As far as performance goes, I'm only looking at branch in add_path()
> that calls compare_pathkeys(). Do you have some example queries which
> would be a worst case for that path?

I think we must be talking past each other somehow. It seems to me
that your scheme would require replacing that branch with something
more complicated or generalized. If it doesn't, then I don't
understand the proposal. If it does, then that seems like it could be
a problem.

> In general if you can post some details about how you are measuring,
> that would be helpful.

I'm not really measuring anything at this point, just recalling the
many previous times when add_path() has been discussed as a pain
point.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2024-08-30 20:07:30 Re: Pgstattuple on Sequences: Seeking Community Feedback on Potential Patch
Previous Message Andrew Dunstan 2024-08-30 19:49:57 Re: pl/pgperl Patch for adding $_FN detail just like triggers have for $_TD