Skip site navigation (1) Skip section navigation (2)

Re: Surfacing qualifiers

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Fetter <david(at)fetter(dot)org>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Surfacing qualifiers
Date: 2008-03-26 18:03:58
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
David Fetter <david(at)fetter(dot)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
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

In response to


pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2008-03-26 18:16:19
Subject: Re: Sending queries directly
Previous:From: Alvaro HerreraDate: 2008-03-26 17:48:23
Subject: Re: PostgreSQL Replication with read-only access tostandby DB

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group