On 8 May 2014 01:49, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote:
>> > * ForeignScan node that is not associated with a particular foreign-table.
>> > Once we try to apply ForeignScan node instead of Sort or Aggregate,
>> existing
>> > FDW implementation needs to be improved. These nodes scan on a
>> materialized
>> > relation (generated on the fly), however, existing FDW code assumes
>> > ForeignScan node is always associated with a particular foreign-table.
>> > We need to eliminate this restriction.
>>
>> I don't think we need to do that, given the above.
>>
> It makes a problem if ForeignScan is chosen as alternative path of Join.
>
> The target-list of Join node are determined according to the query form
> on the fly, so we cannot expect a particular TupleDesc to be returned
> preliminary. Once we try to apply ForeignScan instead of Join node, it
> has to have its TupleDesc depending on a set of joined relations.
>
> I think, it is more straightforward approach to allow ForeignScan that
> is not associated to a particular (cataloged) relations.
From your description, my understanding is that you would like to
stream data from 2 standard tables to the GPU, then perform a join on
the GPU itself.
I have been told that is not likely to be useful because of the data
transfer overheads.
Or did I misunderstand, and that this is intended to get around the
current lack of join pushdown into FDWs?
Can you be specific about the actual architecture you wish for, so we
can understand how to generalise that into an API?
-- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services