using CustomScan to inject nodes into the plan

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: using CustomScan to inject nodes into the plan
Date: 2015-03-11 19:48:12
Message-ID: 55009BFC.6090700@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi there,

I've been experimenting with using CustomScan to inject nodes into the
plan - I'm experimenting a bit, and this seemed like a nice way to do
that in an extension, outside the tree.

Sadly set_rel_pathlist_hook is not flexible enough, because it only
allows overriding paths for base relations, while I'd like to inject
nodes above joins, for example, so instead of

NesterLoop
-> NestedLoop
-> ...

I could do so something like this

NesterLoop
-> (my node)
-> NestedLoop
-> ...

Fair enough - CustomScan is only meant for base relations, so I get the
hook only fires from set_base_rel_pathlists().

Luckily, there's also planner_hook() where I can inject the CustomScan
node wherever I want, and just pass the executor calls to the child node
in the usual way (ExecInitNode, ExecProcNode, ...).

The one problem with this 'combined' solution however is that CustomScan
requires scanrelid - a valid index into the range table. When injecting
the node directly above a Scan node, that seems to work just fine (just
use the same value), but on other places (e.g. above a join) that's not
possible :-(

I see three options:

(1) creating a fake range table entry in the planner_hook (but for
which relation to choose?)

(2) reusing an existing range table entry (but which one?)

(3) allowing CustomScan either without a valid index into a range
table (or maybe referencing join relations and such)

The first two options seem quite ugly to me - fragile and error prone.
What about the third one?

I realize this is probably a misuse of the CustomScan API, but it's the
best way to inject external nodes into the plan that I'm aware of.

BTW: I know there's a custom-join patch in the current commitfest, but
I'd like to stress out I'm not trying to replace the join itself - I'd
like to inject a node below / above it.

regards

--
Tomas Vondra http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2015-03-11 19:48:35 Re: Precedence of standard comparison operators
Previous Message Robert Haas 2015-03-11 19:36:07 Re: NULL-pointer check and incorrect comment for pstate in addRangeTableEntry