Neil Conway <neilc@samurai.com> writes:
> Certainly I agree with Tom that proper SQL/MED support requires
> significant support from both the executor and the optimizer. This is
> just a quick hack to take advantage of the existing predicate pushdown
> logic -- I just thought it was a cute trick, not something I'd suggest
> we include in mainline sources.

My bad, I had misread where you were pulling the quals from. There are
still too many cases where it wouldn't work (anyplace EXPLAIN shades the
truth, including Params and subplans) but it's not quite as useless as
I first thought.

Possibly the Param issue could be fixed by inserting the current actual
value of the Param instead of listing it out as $n.

The real problem is still going to be joins, though. You'd really
really want the thing to be capable of generating the equivalent of
a nestloop-with-inner-indexscan plan, because that is the only join type
that has any hope of not sucking down the entire content of the remote
table. And that's not gonna happen without some amount of planner
support.

It might be interesting to think about using the planner's
get_relation_info_hook to attach pseudo indexes to RTE_FUNCTION
relations ... though where it gets the data from is not clear.

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

Tom Lane wrote:
> David Fetter <david@fetter.org> 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

I'd like to point out that Remote* might be a bit to narrow because
its also a general potential for SRF functions (e.g. any virtual table
construction). Would certainly be nice if we had a as general approach
as possible.

Cheers
Tino

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