Re: inherit support for foreign tables

On Tue, Jul 1, 2014 at 7:39 AM, Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
wrote:

> (2014/06/30 20:17), Ashutosh Bapat wrote:
>
>> On Mon, Jun 30, 2014 at 4:17 PM, 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:
>>
>
> (2014/06/30 17:47), Ashutosh Bapat wrote:
>>
>
> BTW, why aren't you using the tlist passed to this function? I
>> guess
>> create_scan_plan() passes tlist after processing it, so that
>> should be
>> used rather than rel->reltargetlist.
>>
>
> I think that that would be maybe OK, but I think that it would not
>> be efficient to use the list to compute attrs_used, because the
>> tlist would have more information than rel->reltargetlist in cases
>> where the tlist is build through build_physical_tlist().
>>
>
> In that case, we can call build_relation_tlist() for foreign tables.
>>
>
> Do you mean build_physical_tlist()?
>
>
Sorry, I meant build_path_tlist() or disuse_physical_tlist() whichever is
appropriate.

We may want to modify use_physical_tlist(), to return false, in case of
foreign tables. BTW, it does return false for inheritance trees.

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.
>
>
> Thanks,
>
> Best regards,
> Etsuro Fujita
>

--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company