using CustomScan to inject nodes into the plan

Поиск
Список
Период
Сортировка
От Tomas Vondra
Тема using CustomScan to inject nodes into the plan
Дата
Msg-id 55009BFC.6090700@2ndquadrant.com
обсуждение исходный текст
Ответы Re: using CustomScan to inject nodes into the plan  (Robert Haas <robertmhaas@gmail.com>)
Re: using CustomScan to inject nodes into the plan  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Precedence of standard comparison operators
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: [patch] PL/Python is too lossy with floats