In the last exciting episode, herve@elma.fr (Hervé Piedvache) wrote:
> Le Jeudi 20 Janvier 2005 16:05, Joshua D. Drake a écrit :
>> Christopher Kings-Lynne wrote:
>> >>> Or you could fork over hundreds of thousands of dollars for Oracle's
>> >>> RAC.
>> >>
>> >> No please do not talk about this again ... I'm looking about a
>> >> PostgreSQL solution ... I know RAC ... and I'm not able to pay for a
>> >> RAC certify hardware configuration plus a RAC Licence.
>> >
>> > There is absolutely zero PostgreSQL solution...
>>
>> I just replied the same thing but then I was thinking. Couldn't he use
>> multiple databases
>> over multiple servers with dblink?
>>
>> It is not exactly how I would want to do it, but it would provide what
>> he needs I think???
>
> Yes seems to be the only solution ... but I'm a little disapointed about
> this ... could you explain me why there is not this kind of
> functionnality ... it seems to be a real need for big applications no ?
If this is what you actually need, well, it's something that lots of
people would sort of like to have, but it's really DIFFICULT to
implement it.
Partitioning data onto different servers appears like it ought to be a
good idea. Unfortunately, getting _exactly_ the right semantics is
hard.
If the data is all truly independent, then it's no big deal; just have
one server for one set of data, and another for the other.
But reality normally is that if you _think_ you need a cluster, that's
because some of the data needs to be _shared_, which means you need to
either:
a) Have queries that run across two databases, or
b) Replicate the shared data between the systems.
We're likely back to the need for replication.
--
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me
http://www3.sympatico.ca/cbbrowne/rdbms.html
"It is the user who should parameterize procedures, not their
creators." -- Alan Perlis
