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  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Long paths for tablespace leads to uninterruptible hang in Windows
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: Autonomous Transaction (WIP)