Re: Odd system-column handling in postgres_fdw join pushdown patch

(2) when any of
>> xmins, xmaxs, cmins, and cmaxs are requested, postgres_fdw gives up
>> pushing down foreign joins. (We might be able to set appropriate
>> values
>> for them locally the same way as for tableoids, but I'm not sure it's
>> worth complicating the code.) I think that would be probably OK,
>> because users wouldn't retrieve any such columns in practice.
>>
>
> In that patch you have set pushdown_safe to false for the base relation
>> fetching system columns. But pushdown_safe = false means that that
>> relation is not safe to push down. A base foreign relation is always
>> safe to push down, so should have pushdown_safe = true always. Instead,
>> I suggest having a separate boolean has_unshippable_syscols (or
>> something with similar name) in PgFdwRelationInfo, which is set to true
>> in such case. In foreign_join_ok, we return false (thus not pushing down
>> the join), if any of the joining relation has that attribute set. By
>> default this member is false.
>>
>
> Maybe I'm missing something, but why do you consider that base foreign
> tables need always be safe to push down? IIUC, the pushdown_safe flag is
> used only for foreign_join_ok, so I think that a base foreign table needs
> not necessarily be safe to push down.
>
>
A base foreign table "always" fetches data from the foreign server, so it
"has to be" always safe to push down. pushdown_safe flag is designated to
tell whether the relation corresponding to PgFdwRelationInfo where this
flag is set is safe to push down.Right now it's only used for joins but in
future it would be used for any push down of higher operations. It seems
very much possible after the upper pathification changes. We can not have a
query sent to the foreign server for a relation, when pushdown_safe is
false for that. Your patch does that for foreign base relation which try to
fetch system columns.

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