Re: inherit support for foreign tables
От | Etsuro Fujita |
---|---|
Тема | Re: inherit support for foreign tables |
Дата | |
Msg-id | 53B25B6C.7020504@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: inherit support for foreign tables (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>) |
Ответы |
Re: inherit support for foreign tables
|
Список | pgsql-hackers |
(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: > We may want to modify use_physical_tlist(), to return false, in case of > foreign tables. BTW, it does return false for inheritance trees. Yeah, but please consider cases where foreign tables are not inheritance child rels (and any system columns are requested). > 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. Maybe I'm missing something, but what's the point of using the tlist, not reltargetlist? Thanks, Best regards, Etsuro Fujita
В списке pgsql-hackers по дате отправления: