On 10/4/24 01:35, Robert Haas wrote:
On Mon, Sep 30, 2024 at 5:50 AM Andrei Lepikhov <lepi...@gmail.com> wrote:
In attachment - hooks for add_path and add_partial_path. As you can see,
because of differences in these routines hooks also implemented
differently. Also the compare_path_costs_fuzzily is exported, but it is
really good stuff for an extension.
I agree that this is more flexible, but it also seems like it would be
a lot more expensive. For every add_path() or add_partial_path() call,
you'll have to examine the input path and decide what you want to do
with it. If you want to do something like avoid nested loops with
materialization, you'll need to first check the top-level node, and
then if it's a nested loop, you have to check the inner subpath to see
if it's a Materialize node.
I agree, and as you can see, the first simple test on a NestLoop already
avoids further checks for lots of calls for baserels, upper rels, Hash-
and MergeJoins, relieving the issue.
I'm not completely against having something like this; I think there
are cases where something along these lines is the only way to achieve
some desired objective. But I don't think this kind of hook should be
the primary way for extensions to control the planner; it seems too
low-level to me.
It is a fact. Maybe I was unclear, but I usually use it as an addition
to planner_hook or pathlist hooks to have some guarantee or, at least,
have a chance to do something if another path is much better and is
going to displace my path. Sometimes it is just a way to remove a path
from the pathlist without playing games with costs of my path.
I spent some time discovering the pg_hint_plan extension to apprehend
when extensions need to make massive core code copying and IMO, Michael
has the most to say here.
--
regards, Andrei Lepikhov
