Re: Status of FDW pushdowns

From: Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com>
To: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Denis Lussier <denis(dot)lussier(at)openscg(dot)com>
Subject: Re: Status of FDW pushdowns
Date: 2013-11-22 00:41:13
Message-ID: CAEZqfEc_a0MBm3RsWgJEKB9i4V8C4BF5_LdLAmAyUOYJHA=C6Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2013/11/22 Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>:
> 2013/11/21 Bruce Momjian <bruce(at)momjian(dot)us>:
>> Where are we on the remaining possible pushdowns for foreign data
>> wrappers, particularly the Postgres one? I know we do WHERE restriction
>> pushdowns in 9.3, but what about join and aggregate pushdowns? Is
>> anyone working on those?
>>
>> I know join pushdowns seem insignificant, but it helps to restrict what
>> data must be passed back because you would only pass back joined rows.
>>
>> Do we document these missing features anywhere?
>>
> Probably, custom-scan api will provide more flexible way to push-down
> aggregate, sort or other stuff performing on regular tables, not only
> foreign tables.
> It allows extensions to offer alternative scan/join path on the planning
> stage, then executor callbacks its custom logic instead of the built-in
> one, if its cost is cheaper.

IIRC, sort push-down is already supported. We can provide sorted
pathes by setting Pathkeys to additional ForeignPath. postgres_fdw
doesn't support this feature because we couldn't get consensus about
how to limit sort variation. One idea was to allow to define "foreign
index" on foreign tables to indicate which column combination is
reasonably sortable.
--
Shigeru HANADA

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Shigeru Hanada 2013-11-22 00:43:18 Re: Status of FDW pushdowns
Previous Message Tom Lane 2013-11-22 00:40:25 Re: UNNEST with multiple args, and TABLE with multiple funcs