On 2015/10/21 13:34, Kouhei Kaigai wrote:
>> On 2015/10/20 13:11, Etsuro Fujita wrote:
>>> On 2015/10/20 5:34, Robert Haas wrote:
>>>> No. You just need to populate fdw_recheck_quals correctly, same as
>>>> for the scan case.
>> As I said yesterday, that opinion of me is completely wrong. Sorry for
>> the incorrectness. Let me explain a little bit more. I still think
>> that even if ROW_MARK_COPY is in use, we would need to locally rejoin
>> the tuples populated from the whole-row images for the foreign tables
>> involved in a remote join, using a secondary plan. Consider eg,
>>
>> SELECT localtab.*, ft2 from localtab, ft1, ft2
>> WHERE ft1.x = ft2.x AND ft1.y = localtab.y FOR UPDATE
>>
>> In this case, since the output of the foreign join would not include any
>> ft1 columns, I don't think we could do the same thing as for the scan
>> case, even if populating fdw_recheck_quals correctly.
> As an aside, could you introduce the reason why you think so? It is
> significant point in discussion, if we want to reach the consensus.
> On the other hands, the joined-tuple we're talking about in this context
> is a tuple prior to projection; formed according to the fdw_scan_tlist.
> So, it contains all the necessary information to run scan/join qualifiers
> towards the joined-tuple. It is not affected by the target-list of user
> query.
After research into the planner, I noticed that I was still wrong; IIUC,
the planner requires that the output of foreign join include the column
ft1.y even for that case. (I don't understand the reason why the
planner requires that.) So, as Robert mentioned, the clause ft1.y =
localtab.y could be rechecked during an EPQ recheck, if populating
fdw_recheck_quals correctly. Sorry again for the incorrectness.
> Even though I think the approach with joined-tuple reconstruction is
> reasonable solution here, it is not a fair reason to introduce disadvantage
> of Robert's suggestion.
Agreed.
> Also, please don't mix up "what we do" and "how we do".
>
> It is "what we do" to discuss which format of tuples shall be returned
> to the core backend from the extension, because it determines the role
> of interface. If our consensus is to return a joined-tuple, we need to
> design the interface according to the consensus.
>
> On the other hands, it is "how we do" discussion whether we should
> enforce all the FDW/CSP extension to have alternative plan, or not.
> Once we got a consensus in "what we do" discussion, there are variable
> options to solve the requirement by the consensus, however, we cannot
> prioritize "how we do" without "what we do".
Agreed.
Best regards,
Etsuro Fujita
