Re: Partitioning / Clustering

Alex,

> 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:
www.bizgres.org  / http://pgfoundry.org/projects/bizgres/
... 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.
www.greenplum.com.

If you have more time than money, I understand that Stanford is working on
this problem:
http://www-db.stanford.edu/~bawa/

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