> This is why I mention partitioning. It solves this issue by storing  
> different data sets on different machines under the same schema.  

That's clustering, actually.  Partitioning is simply dividing up a table into 
chunks and using the chunks intelligently.   Putting those chunks on seperate 
machines is another thing entirely.  

We're working on partitioning through the Bizgres sub-project:  /
... and will be pushing it to the main PostgreSQL when we have something.

I invite you to join the mailing list.

> These seperate chunks of the table can then be replicated as well for  
> data redundancy and so on. MySQL are working on these things, 

Don't hold your breath.   MySQL, to judge by their first "clustering" 
implementation, has a *long* way to go before they have anything usable.  In 
fact, at OSCON their engineers were asking Jan Wieck for advice.

If you have $$$ to shell out, my employer (GreenPlum) has a multi-machine 
distributed version of PostgreSQL.  It's proprietary, though.

If you have more time than money, I understand that Stanford is working on 
this problem:

But, overall, some people on this list are very mistaken in thinking it's an 
easy problem.   GP has devoted something like 5 engineers for 3 years to 
develop their system.  Oracle spent over $100 million to develop RAC.  

> but PG   
> just has a bunch of third party extensions, I wonder why these are  
> not being integrated into the main trunk :/ 

Because it represents a host of complex functionality which is not applicable 
to most users?  Because there are 4 types of replication and 3 kinds of 
clusering and not all users want the same kind?

Josh Berkus
Aglio Database Solutions
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Reply via email to