On 22/05/12 13:47, Simon Riggs wrote:
> On 22 May 2012 12:35, Florian Pflug<fgp@phlo.org> wrote:
>>> * Allow users to access tables in>1 database easily, with appropriate rights.
>> That one I'm very sceptical about. In the long run, I think we want better
>> separation of databases, not less, and this requirement carries a huge risk
>> of standing in the way of that. Also, I think that once we integrate the postgres
>> FDW into core (that's the plan in the long run, right?), we're going to get
>> a good approximation of that essentially for free.
> It's a poor approximation of it, free or not.
>
> If it actually worked well, I'd be happy. It doesn't. No proper
> transaction support, no session pool, poor planning etc etc. At best
> its a band-aid, not something sufficiently good to recommend for
> general production use.
- Transaction support: should be fixed, I guess.
- Session pool: is this really needed? I would it externally -- for
example, by specifying a connection string to a pgPool/pgBouncer as
opposed to directly to the db server.
- Planning: add a tunable specifying a higher cost (with a exception for
cluster-local dblinks, which would have a lower cost), and the rest
should be straightforward. Of course, planning would'nt be as accurate
---we can't access the other db statistics in order to potentially
rewrite conditions---, but I don't think that would be a proper approach
(separation concerns, again)
> FDWs are very good but aren't good enough for intra-database usage.
The optimization I just proposed (plus the required fixes to FDW) might
very well solve this, while providing useful enhancements for all users,
whether they are accessing cluster-local databases or not (or even truly
foreign datasources)
Regards,
Jose Luis Tallon