From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | shigeo Hirose <shigeo(dot)hirose(at)toshiba(dot)co(dot)jp>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: How can I pushdown of functions used in targetlist with FDW ? |
Date: | 2020-01-09 17:09:00 |
Message-ID: | 20200109170900.GU3195@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Greetings,
* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> shigeo Hirose <shigeo(dot)hirose(at)toshiba(dot)co(dot)jp> writes:
> > How can I pushdown of functions used in targetlist with FDW ?
>
> There is, AFAIK, no provision for that. There's not a lot of
> reason to consider adding it either, because there's no reason
> to suppose that the remote node can run such a function any
> faster than the local node. So the difficulty and risk of
> determining/assuming that f(x) on the local node is the same
> as f(x) on the remote node doesn't seem like it'd be repaid.
Well, for starters, isn't there something in the SQL/MED spec about
this..?
Next, we already do this for aggregates.
Also, I don't think I agree with this particular position- it's entirely
possible that the remote server is much less loaded/busy than the local
one and therefore it'd be beneficial, overall, to run that function on
the remote system and not the local one. The function might even have
side-effects or use other objects in the system to run. The function
may also return a much smaller result than pulling back the raw data (of
course, the opposite could also possibly be true).
I guess my gut feeling is that, in general, we should push down as much
of the query as possible, as we do for aggregates and joins and
conditionals. I appreciate that there's some complications here when it
comes to figuring out if it's possible/reasonable to push down something
like, say, a volatile function that's locally defined and known to exist
on the remote. Haven't got a particular idea how to address that
offhand but that doesn't change my feelings that we should have a way to
do this generally and that it would actually be useful to have.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Lewis | 2020-01-09 17:15:10 | Re: partitioned table |
Previous Message | Pepe TD Vo | 2020-01-09 17:06:43 | partitioned table |