Re: PG9.2 and FDW query planning. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: PG9.2 and FDW query planning.
Date
Msg-id 28076.1341505808@sss.pgh.pa.us
Whole thread Raw
In response to PG9.2 and FDW query planning.  (Ronan Dunklau <rdunklau@gmail.com>)
Responses Re: PG9.2 and FDW query planning.  (Ronan Dunklau <rdunklau@gmail.com>)
List pgsql-hackers
Ronan Dunklau <rdunklau@gmail.com> writes:
> Let's say I have an IMAP foreign data wrapper, and I write a query
> joining the table on itself using the In-Reply-To and Message-ID
> headers, is there anything I can do to avoid fetching all the mails
> from the remote server ?

> If I could somehow inform the planner that it can look up rows by
> message-id, thus avoiding the need to fetch everything from the remote
> server. Perhaps "persuading" the planner to use a nested-loop ?

OK, so what you're saying is that the imap server can effectively
provide an index on message_id.  What you'd do is create a parameterized
path that uses the tbl.message_id = other_tbl.in_reply_to join clause.
If that's enough cheaper than a full scan, the planner would select it.

FWIW, I'm not sure that it's sane to try to expose this stuff to python
yet.  It's complicated and still something of a moving target.  Once
we've got a few more C-coded FDWs that can do this type of optimization,
things might be stable enough that it'd be useful to try to provide a
high-level API.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Joel Jacobson
Date:
Subject: Re: Schema version management
Next
From: Alvaro Herrera
Date:
Subject: Re: Schema version management