(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
step 1>)
3. then join the original set to selected set, with any suitable join
strategy

The things I do not want are

A. selecting all rows from remote table
     (this is what your examples below do)

or

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
itself

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.

Thanks,

P.S.
or, that as Tom mentioned, by disabling the use_remote_estimate function:

I misunderstood the meaning of what Tom pointed out.  Sorry for that.

Best regards,
Etsuro Fujita


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to