On Tue, 28 Jun 2011 17:04:54 -0600, Rob Sargent wrote:
On 06/28/2011 04:52 PM, Greg Smith wrote:
On 06/28/2011 05:45 PM, Rob Sargent wrote:
I think Greg might be forgetting that some of us don't always get
to
choose what we work on. I was in a shop that decided to go with
multi-tenancy for reason both technical and um, er envious.
There are certainly successful deployments of multi-tenant
PostgreSQL
out there, ones that make sense. What I was trying to communicate
is
that the particular variation proposed by this academic paper
doesn't
seem the right direction for PostgreSQL development to head in to
me.
This project is stubborn about resolving the problems people
actually
have, and the ones the paper tries to solve are not the ones I've
seen
in my own experiments in multi-tenant deployments.
Yes, your point is well taken here, and that wasn't even hinted at in
my
previous (top! oops) post. My point was that hacks in the field
(i.e.
me) will have to do multi-tenancy on postgres and though this
implementation may not become the answer, any leg up would be
appreciated.
I think this may be quite interesting solution. Actually I created such
approach, for many reasons, but it's hard-coded, I mean in any place
when query is executed I add this "tenancy" id, I called it differently,
and it works perfectly.
But such feature will not grow quite fast until PostgreSQL "ecosystem"
will not grow, for example I see problems with Java + Hibernate +
Caching, when "tenancy" id will be hidden, actually You may query for
two "different" objects with same id, if we will allow dynamic tanacy
switch (should be done, as You will loose connection pool benefits).
Regards,
Radek
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
