Re: Changing the concept of a DATABASE

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