(2014/04/16 22:16), Hannu Krosing wrote:
On 04/16/2014 01:35 PM, Etsuro Fujita wrote:
Maybe I'm missing something, but I think that you can do what I think
you'd like to do by the following procedure:
No, what I'd like PostgreSQL to do is to
1. select the id+set from local table
2. select the rows from remote table with WHERE ID IN (<set selected in
3. then join the original set to selected set, with any suitable join
The things I do not want are
A. selecting all rows from remote table
(this is what your examples below do)
B. selecting rows from remote table by single selects using "ID = $"
(this is something that I managed to do by some tweaking of costs)
as A will be always slow if there are millions of rows in remote table
and B is slow(ish) when the idset is over a few hundred ids
I hope this is a bit better explanation than I provided before .
Ah, I understand what you'd like to do. Thank you for the explanation.
P.S. I am not sure if this is a limitation of postgres_fdw or postgres
If I understand correctly, neither the current postgres_fdw planning
function nor the current postgres planner itself support such a plan.
For that I think we would probably need to implement a distributed query
processing technique such as semijoin or bloomjoin in those modules.
or, that as Tom mentioned, by disabling the use_remote_estimate function:
I misunderstood the meaning of what Tom pointed out. Sorry for that.
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: