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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
