On Thu, Oct 29, 2015 at 6:05 AM, Kouhei Kaigai <kai...@ak.jp.nec.com> wrote: > In this case, the EPQ slot to store the joined tuple is still > a challenge to be solved. > > Is it possible to use one or any of EPQ slots that are setup for > base relations but represented by ForeignScan/CustomScan?
Yes, I proposed that exact thing upthread. > In case when ForeignScan run a remote join that involves three > base foreign tables (relid=2, 3, 5 for example), for example, > no other code touches this slot. So, it is safe even if we put > a joined tuple on EPQ slots of underlying base relations. > > In this case, EPQ slots are initialized as below: > > es_epqTuple[0] ... EPQ tuple of base relation (relid=1) > es_epqTuple[1] ... EPQ of the joined tuple (for relis=2, 3 5) > es_epqTuple[2] ... EPQ of the joined tuple (for relis=2, 3 5), copy of above > es_epqTuple[3] ... EPQ tuple of base relation (relid=4) > es_epqTuple[4] ... EPQ of the joined tuple (for relis=2, 3 5), copy of above > es_epqTuple[5] ... EPQ tuple of base relation (relid=6) You don't really need to initialize them all. You can just initialize es_epqTuple[1] and leave 2 and 4 unused. > Then, if FDW/CSP is designed to utilize the preliminary joined > tuples rather than local join, it can just raise the tuple kept > in one of the EPQ slots for underlying base relations. > If FDW/CSP prefers local join, it can perform as like local join > doing; check join condition and construct a joined tuple by itself > or by alternative plan. Right. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
