Kohei KaiGai <kai...@kaigai.gr.jp> writes:
> Right now, it performs on relation scan or join only. However, we will be
> able to apply same concept on aggregation.
> For example, an aggregation node on a foreign table scan is a good
> candidate to push down because it can be replaced with a custom-
> logic that scans a materialized result of the remote aggregation query,
> if its cost is enough cheap than local aggregation.
> Probably, we need to add a hook and some logic to compare the
> built-in aggregation and alternative paths provided by extensions.
Note that this is another thing that's blocked on Path-ifying the work
now done in grouping_planner. We don't currently have a way to represent
a local aggregation, much less a remote one, as a Path. We definitely
need that before we can open up any of that logic to FDWs.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
