On Tue, May 22, 2012 at 8:40 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
> That seems to be leaving aside the fact that we don't currently have any
> notion of how to allow FDWs to write the foreign tables.
>
> What is more, isn't the postgres FDW about talking to any postgres source?
> If so, does it have special smarts for when we are talking to ourselves? And
> if it doesn't then it seems unlikely to be an acceptable substitute for
> allowing talking direct to a sibling database.
>
> I'm not at all yet sold on Simon's plan, but I'm skeptical that an FDW would
> adequately meet the case if we wanted to go that way.
Well, I don't think anyone is claiming that FDWs as they exist today
solve all of the problems in this area. But I think that improving
FDWs is a more promising line of attack than trying to make backends
talk to multiple databases. Doing the latter will require massive
surgery on the relcache, the catcache, most of the secondary catalog
caches, the ProcArray, and every portion of the backend that thinks an
OID uniquely identifies an SQL object. Basically, they'd all need
database OID as an additional key field, which is undesirable for
performance reasons even if there were no issue of code churn.
So I'd rather see us put the effort into pgsql_fdw, which, as Florian
says, will also let us talk to a completely separate server. If
you've got multiple databases in the same cluster and really need to
be doing queries across all of them, that's what schemas are
supposedly for. Now I know that people feel that doesn't work as well
as it needs to, but there again I think it would be easier to fix
schemas than to make cross-database queries work.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company