Re: PG9.2 and FDW query planning.
От | Tom Lane |
---|---|
Тема | Re: PG9.2 and FDW query planning. |
Дата | |
Msg-id | 28076.1341505808@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | PG9.2 and FDW query planning. (Ronan Dunklau <rdunklau@gmail.com>) |
Ответы |
Re: PG9.2 and FDW query planning.
|
Список | 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 по дате отправления: