Re: Join push-down support for foreign tables - Mailing list pgsql-hackers

From Atri Sharma
Subject Re: Join push-down support for foreign tables
Date
Msg-id CAOeZVifadF4fP-_uxWEsjU3GsBiYu7u1qGbLK8-2PdfUskY8wQ@mail.gmail.com
Whole thread Raw
In response to Re: Join push-down support for foreign tables  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Join push-down support for foreign tables  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers


On Thursday, September 4, 2014, Bruce Momjian <bruce@momjian.us> wrote:
On Thu, Sep  4, 2014 at 08:37:08AM -0400, Robert Haas wrote:
> The main problem I see here is that accurate costing may require a
> round-trip to the remote server.  If there is only one path that is
> probably OK; the cost of asking the question will usually be more than
> paid for by hearing that the pushed-down join clobbers the other
> possible methods of executing the query.  But if there are many paths,
> for example because there are multiple sets of useful pathkeys, it
> might start to get a bit expensive.
>
> Probably both the initial cost and final cost calculations should be
> delegated to the FDW, but maybe within postgres_fdw, the initial cost
> should do only the work that can be done without contacting the remote
> server; then, let the final cost step do that if appropriate.  But I'm
> not entirely sure what is best here.

I am thinking eventually we will need to cache the foreign server
statistics on the local server.



Wouldn't that lead to issues where the statistics get outdated and we have to anyways query the foreign server before planning any joins? Or are you thinking of dropping the foreign table statistics once the foreign join is complete?

Regards,

Atri 


--
Regards,
 
Atri
l'apprenant

pgsql-hackers by date:

Previous
From: Joel Jacobson
Date:
Subject: Re: PL/pgSQL 1.2
Next
From: Joel Jacobson
Date:
Subject: Re: PL/pgSQL 1.2