public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tom Lane <[email protected]>
To: Robert Haas <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: allowing extensions to control planner behavior
Date: Mon, 26 Aug 2024 13:37:34 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <CA+TgmoZY+baV-T-5ifDn6P=L=aV-VkVBrPmi0TQkcEq-5Finww@mail.gmail.com>
References: <CA+TgmoZY+baV-T-5ifDn6P=L=aV-VkVBrPmi0TQkcEq-5Finww@mail.gmail.com>
Robert Haas <[email protected]> writes:
> I'm somewhat expecting to be flamed to a well-done crisp for saying
> this, but I think we need better ways for extensions to control the
> behavior of PostgreSQL's query planner.
Nah, I won't flame you for that, it's a reasonable thing to think
about. However, the devil is in the details, and ...
> The attached patch, briefly mentioned above, essentially converts the
> enable_* GUCs into RelOptInfo properties where the defaults are set by
> the corresponding GUCs.
... this doesn't seem like it's moving the football very far at all.
The enable_XXX GUCs are certainly blunt instruments, but I'm not sure
how much better it is if they're per-rel. For example, I don't see
how this gets us any closer to letting an extension fix a poor choice
of join order. Or, if your problem is that the planner wants to scan
index A but you want it to scan index B, enable_indexscan won't help.
> ... On the other hand, the more I look at
> what our enable_* GUCs actually do, the less impressed I am. IMHO,
> things like enable_hashjoin make a lot of sense, but enable_sort seems
> like it just controls an absolutely random smattering of behaviors in
> a way that seems to me to have very little to recommend it, and I've
> complained elsewhere about how enable_indexscan and
> enable_indexonlyscan are really quite odd when you look at how they're
> implemented.
Yeah, these sorts of questions aren't made better this way either.
If anything, having extensions manipulating these variables will
make it even harder to rethink what they do.
You mentioned that there is prior art out there, but this proposal
doesn't seem like it's drawing on any such thing. What ideas should
we be stealing?
regards, tom lane
view thread (4+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: allowing extensions to control planner behavior
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox