The attached patches include documentation fixup by Hanada-san,
and relocation of is_managed_relation (the portion to check whether
the relation is a foreign table managed by a particular FDW) and
has_wholerow_reference.
I didn't touch the EXPLAIN logic because I'm uncertain whether the
cost of remote join is reasonable towards the cost as an alternative
path to local joins.
Please check it. Thanks,
2013/12/5 Kohei KaiGai <kaigai@kaigai.gr.jp>:
> Hanada-san,
>
> Thanks for your reviewing,
>
> 2013/12/4 Shigeru Hanada <shigeru.hanada@gmail.com>:
>> I first reviewed postgres_fdw portion of the patches to learn the
>> outline of Custom Plan. Wiki page is also a good textbook of the
>> feature. I have some random comments about the basic design of Custom
>> Plan:
>>
>> (1) IIUC add_join_path and add_scan_path are added to allow extensions
>> to plug their code into planner.
>>
> Almost yes. For more correctness, these hooks allows extensions to
> plug paths they can provide into a particular join or scan. Then planner
> will choose the cheapest one according to the cost value.
>
>> (2) FDW framework has executor callbacks based on existing executor
>> nodes. Is there any plan to integrate them into one way, or wrap on
>> by another? I'm not sure that we should have two similar framework
>> side by side.
>> # I'm sorry if I've missed the past discussion about this issue.
>>
> Probably, FDW has different role from the CustomScan API.
> As literal, FDW performs as a bridge between a relation form and
> an opaque external data source, to intermediate two different world
> on behalf of a foreign table.
> On the other hand, CustomScan allows to provide alternative logic
> to scan or join particular relations, in addition to the built-in ones,
> but does not perform on behalf of foreign tables.
>
> Existing FDW is designed to implement a scan on an intangible
> relation, thus it can assume some things; like a tuple returned
> from FDW has equivalent TupleDesc as table definition, or it can
> always use ExecScan() for all the cases.
> So, I don't think these two frameworks should be consolidated
> because it makes confusion on the existing extensions that
> assumes FDW callbacks always has a particular foreign table
> definition.
>
>> (3) Internal routines such as is_self_managed_relation and
>> has_wholerow_reference seem to be useful for other FDWs. Is it able
>> to move them into core?
>>
> Probably, src/backend/foreign/foreign.c is a good host for them.
>
>> (4) postgres_fdw estimates costs of join by calculating local numbers.
>> How about to support remote estimation by throwing EXPLALAIN query
>> when use_remote_estimates = true.
>>
> I'm uncertain whether the cost value from remote EXPLAIN represents
> right difficulty on the local side, because it indeed represents the
> difficulty to join two relations on the remote side, however, does not
> represents local job; that just fetches tuples from the result set of
> remote query with table joining.
> How about your opinion? Is the remote cost estimation value comparable
> with local value?
>
> Thanks,
> --
> KaiGai Kohei <kaigai@kaigai.gr.jp>
--
KaiGai Kohei <kaigai@kaigai.gr.jp>