Re: Hooking at standard_join_search (Was: Re: Foreign join pushdown vs EvalPlanQual)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Hooking at standard_join_search (Was: Re: Foreign join pushdown vs EvalPlanQual)
Дата
Msg-id 9563.1441217036@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Hooking at standard_join_search (Was: Re: Foreign join pushdown vs EvalPlanQual)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
I wrote:
> ... I imagine that we should allow FDWs to
> store some data within RelOptInfo structs that represent foreign joins
> belonging entirely to them, so that there'd be a handy place to keep that
> data till later.

Actually, if we do that (ie, provide a "void *fdw_state" field in join
RelOptInfos), then the FDW could use the nullness or not-nullness of
such a field to realize whether or not it had already considered this
join relation.  So I'm now thinking that the best API is to call the
FDW at the end of each make_join_rel call, whether it's the first one
for the joinrel or not.  If the FDW wants a call for each legal pair of
input sub-relations, it's got one.  If it only wants one call per joinrel,
it can just make sure to put something into fdw_state, and then on
subsequent calls for the same joinrel it can just exit immediately if
fdw_state is already non-null.  So we have both use-cases covered.
Also, by doing this at the end, the FDW can look at the "regular" (local
join execution) paths that were already generated, should it wish to.
        regards, tom lane



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

Предыдущее
От: Merlin Moncure
Дата:
Сообщение: Re: Horizontal scalability/sharding
Следующее
От: Fabien COELHO
Дата:
Сообщение: Re: pgbench stats per script & other stuff