On 22/05/12 13:24, Simon Riggs wrote:
On 22 May 2012 12:05, José Luis Tallón<jltal...@nosys.es> wrote:
IMVHO: s/database/schema/g does resolve many of the problems that you were
referring to... and 'dblink' should solve the rest, right?
Please, feel free to point out what I am (most probably) not considering --
not experienced enough yet :)
The choice of schema/database is an important one. If you get it
wrong, you are in major difficulty. In many cases schemas would be a
better choice, but not in all cases. So I'm interested in solving the
problems for people who have multiple databases on same server.
Ok. Understood.
Thank you for the clarification
dblink is the only solution, but its very poor way to do this when we
have 2 databases on same server.
My thinking is that reaching out to multiple databases is actually
mostly easy, except in a few places where dbid is hardwired into the
backend.
The only drawback I see is that it might weaken the separation.
Even though arguably a kludge, dblink could have a "shortcut" added,
whereby connections to another database within the same cluster would be
serviced directly within the backend, as opossed to opening a new db
connection. This is effectively a fastpath within dblink, which
optimizes a relatively common case while at the same time not loosing
generality.
On the other hand, the separation of databases allows what otherwise would
only be possible by using multiple instances of the database server (à la
Oracle, AFAIK ) -- save for resource management, but that is another
question whatsoever.
Separation of databases is fine. I have no intention to change that,
as long as the user wishes that.
Perfect.
Thanks,
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
