Re: Surfacing qualifiers - Mailing list pgsql-hackers

From David Fetter
Subject Re: Surfacing qualifiers
Date
Msg-id 20080326220458.GH30828@fetter.org
Whole thread Raw
In response to Re: Surfacing qualifiers  (Neil Conway <neilc@samurai.com>)
List pgsql-hackers
On Wed, Mar 26, 2008 at 02:26:41PM -0700, Neil Conway wrote:
> On Wed, 2008-03-26 at 14:38 -0400, Andrew Dunstan wrote:
> > I'm still waiting to see an example of where you say this patch is
> > even marginally useful.
> 
> It's not hard to think of one:
> 
> SELECT * FROM remote_table() WHERE x = 5;

In DBI-Link's case, remote_table() may not have all the nice features
a Postgres data store would.  It might or might not have indexes, for
example, and the best hints it could get might well be those
predicates supplied by DBI-Link.

> Applying the predicate on the remote database (pushing the predicate
> below the function scan) is an elementary optimization, and in many
> cases would be enormously more efficient than materializing the
> entire remote table at the local site and then applying the qual
> there.
> 
> 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.

I disagree that it's "just" a cute trick.  I've managed to get dblink
to use it transparently with dblink :)

Cheers,
David.
-- 
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Timing of parameter/variable name lookup vs legacy behaviors
Next
From: Greg Smith
Date:
Subject: Windows shared_buffers limitations