Re: inherit support for foreign tables
От | Ashutosh Bapat |
---|---|
Тема | Re: inherit support for foreign tables |
Дата | |
Msg-id | CAFjFpRf2+e9E9hoFF+3pVdHG+mxNqYDqs7iwkXzme5vCqo8bjw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: inherit support for foreign tables (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>) |
Ответы |
Re: inherit support for foreign tables
|
Список | pgsql-hackers |
On Tue, Jul 1, 2014 at 12:25 PM, Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> wrote:
(2014/07/01 15:13), Ashutosh Bapat wrote:On Tue, Jul 1, 2014 at 7:39 AM, Etsuro Fujita<fujita.etsuro@lab.ntt.co.jp <mailto:fujita.etsuro@lab.ntt.co.jp>> wrote:Yeah, but please consider cases where foreign tables are not inheritance child rels (and any system columns are requested).We may want to modify use_physical_tlist(), to return false, in case of
foreign tables. BTW, it does return false for inheritance trees.Maybe I'm missing something, but what's the point of using the tlist, not reltargetlist?486 /*
487 * Can't do it with inheritance cases either (mainly because
Append
488 * doesn't project).
489 */
490 if (rel->reloptkind != RELOPT_BASEREL)
491 return false;
Yeah, we can call build_physical_tlist() (and do that in some
cases), but if we call the function, it would generate a tlist that
contains all Vars in the relation, not only those Vars actually
needed by the query (ie, Vars in reltargetlist), and thus it would
take more cycles to compute attr_used from the tlist than from
reltargetlist. That' what I wanted to say.
Compliance with other create_*scan_plan() functions. The tlist passed to those functions is sometimes preprocessed in create_scan_plan() and some of the function it calls. If we use reltargetlist directly, we loose that preprocessing. I have not see any of create_*scan_plan() fetch the targetlist directly from RelOptInfo. It is always the one supplied by build_path_tlist() or disuse_physical_tlist() (which in turn calls build_path_tlist()) or build_physical_tlist().
Thanks,
Best regards,
Etsuro Fujita
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
В списке pgsql-hackers по дате отправления: