Re: allowing extensions to control planner behavior

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Robert Haas <robertmhaas(at)gmail(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 17:42:52
Message-ID: 56ebc7c4032e689d39f89dd169665d28edec33da.camel@j-davis.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 2024-08-30 at 07:33 -0400, Robert Haas wrote:
> 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.

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?

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

Regards,
Jeff Davis

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2024-08-30 18:35:53 Re: PG_TEST_EXTRA and meson
Previous Message Paul Jungwirth 2024-08-30 16:26:56 Re: Inline non-SQL SRFs using SupportRequestSimplify