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
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 |