Re: Join push-down support for foreign tables

From: Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Join push-down support for foreign tables
Date: 2014-12-26 04:45:00
Message-ID: CAEZqfEfCaWmukO9wMg92kuSKbCQp0wLtMp1K4jrkTn+KrANT+g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2014-12-16 0:45 GMT+09:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com> writes:
>> I'm working on $SUBJECT and would like to get comments about the
>> design. Attached patch is for the design below. Note that the patch
>> requires Kaigai-san's custom foriegn join patch[1]
>
> For the record, I'm not particularly on-board with custom scan, and
> even less so with custom join. I don't want FDW features like this
> depending on those kluges, especially not when you're still in need
> of core-code changes (which really points up the inadequacy of those
> concepts).

This design derived from discussion about custom scan/join. In that
discussion Robert suggested common infrastructure for replacing Join
path with Scan node. Here I agree to user such common infrastructure.
One concern is introducing hook function I/F which seems to break
FdwRoutine I/F boundary...

>
> Also, please don't redefine struct NestPath like that. That adds a
> whole bunch of notational churn (and backpatch risk) for no value
> that I can see. It might've been better to do it like that in a
> green field, but you're about twenty years too late to do it now.

Ok, will revert it.

--
Shigeru HANADA

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Shigeru Hanada 2014-12-26 04:48:59 Re: Join push-down support for foreign tables
Previous Message Noah Misch 2014-12-26 04:05:46 Re: group locking: incomplete patch, just for discussion