David Fetter <[EMAIL PROTECTED]> writes:
> You mentioned in an earlier mail that the information exposed was
> inadequate. Could you sketch out what information would really be
> needed and where to find it?
The main problem with what you suggest is that it'll fail utterly
on join queries.
AFAICS any real improvement in the situation will require exposing
remote tables as a concept understood by the planner, complete
with ways to obtain index and statistical information at plan time.
After suitable decisions about join strategy and so forth, we'd
wind up with a plan containing a "RemoteTableScan" node which
would have some restriction conditions attached. Then forwarding
those to the remote database would be sensible. But expecting a
dblink function to figure out which clauses are restrictions for
its table, when it doesn't even know what other tables were in
the query, is not sensible.
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
