On 2015/10/01 19:02, Kyotaro HORIGUCHI wrote:
> At Thu, 1 Oct 2015 17:50:25 +0900, Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> wrote in
<560CF3D1.9060305@lab.ntt.co.jp>
>>>> From: pgsql-hackers-owner@postgresql.org
>>>> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Robert Haas
>>>> So, if we wanted to fix this in a way that preserves the spirit of
>>>> what's there now, it seems to me that we'd want the FDW to return
>>>> something that's like a whole row reference, but represents the output
>>>> of the foreign join rather than some underlying base table. And then
>>>> get the EPQ machinery to have the evaluation of the ForeignScan for
>>>> the join, when it happens in an EPQ context, to return that tuple.
>>>> But I don't really have a good idea how to do that.
>> So, I'd like to investigate another approach that preserves the
>> applicability of late row locking to the join pushdown case as well as
>> the spirit of what's there now. The basic idea is (1) add a new
>> callback routine RefetchForeignJoinRow that refetches one foreign-join
>> tuple from the foreign server, after locking remote tuples for the
>> component foreign tables if required,
> It would be the case that at least one of the component relations
> of a foreign join is other than ROW_MARK_COPY, which is not
> possible so far on postgres_fdw.
Yes. To be exact, it's possible for the component relations to have
rowmark methods other than ROW_MARK_COPY using GetForeignRowMarkType, in
principle, but the server crashes ...
> For the case that some of the
> component relations are other than ROW_MARK_COPY, we might should
> call RefetchForeignRow for such relations and construct joined
> row involving ROW_MARK_COPY relations.
You are saying that we should construct the joined row using an
alternative local join execution plan?
> Indeed we could consider some logic for the case, it is obvious
> that the case now we should focus on is a "foreign join" scan
> with all underlying foreign scans are ROW_MARK_COPY, I
> think. "foreign join" scan with ROW_MARK_COPY looks to be
> promising (for me) and in future it would be able to coexist with
> refetch mechanism maybe in your mind from this point of
> view... Maybe:p
I agree that the approach "foreign-join scan with ROW_MARK_COPY" would
be promising.
Best regards,
Etsuro Fujita
