From: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
Cc: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: inherit support for foreign tables |
Date: | 2014-07-01 06:55:40 |
Message-ID: | 53B25B6C.7020504@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
(2014/07/01 15:13), Ashutosh Bapat wrote:
> On Tue, Jul 1, 2014 at 7:39 AM, Etsuro Fujita
> <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp <mailto:fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2014-07-01 06:56:22 | Re: Autonomous Transaction (WIP) |
Previous Message | Amit Kapila | 2014-07-01 06:47:47 | Re: Long paths for tablespace leads to uninterruptible hang in Windows |