Re: [HACKERS] postgres_fdw bug in 9.6

Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> writes:
> (2018/01/16 6:38), Tom Lane wrote:
>> I'm also still pretty unhappy with the amount of useless planning work
>> caused by doing GetExistingLocalJoinPath during path creation. It strikes
>> me that we could likely replace the entire thing with some code that just
>> reconstructs the join node's output tuple during EPQ using the rowmark
>> data for all the base relations.

> The join tuple would be reconstructed without a local join execution plan?

It seems clear to me that this could be done in principle.

>> Outer joins aren't really a problem:
>> we could tell which relations were replaced by nulls because the rowmark
>> values that bubbled up to the top went to nulls themselves.

> Yeah, but we would need null-extension or projection...

Yes, the question is how complicated it would be to get the projection
right. As long as the join node's scan tuple only needs to contain values
(possibly whole-row Vars) propagated up from base relations and possibly
nulled out, it seems like it's not very hard. But if we ever try to
implement actual calculation of expressions in intermediate join nodes,
it could get to be a mess. (I haven't looked at the aggregate-pushdown
patch in this connection, although probably that's not a hazard since
we don't support aggregation together with FOR UPDATE. Perhaps we could
likewise simply refuse to push expressions into foreign join nests if
FOR UPDATE is active.)

As against that, the existing EPQ implementation is pretty messy already,
on top of consuming a lot of planning cycles.

> What do you think about a future extension to parameterized foreign paths?

Don't have an opinion on that; but it doesn't seem like EPQ is the
principal blocking factor there. You could always skip generating
parameterized foreign paths if FOR UPDATE is needed.

regards, tom lane