On 22/05/12 13:47, Simon Riggs wrote:
On 22 May 2012 12:35, Florian Pflug<f...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
