On 9/8/07, novnov <novnovice@xxxxxxxxx> wrote: > > Yes, I realize that scaling must be a large and complicated topic. And that > PostgresSQL is not as scaleable as Oracle etc. Depends on how we're defining scalability. :) I didn't explicitly say that RAC will outscale postgresql. It's just one approach. another approach is getting a bigger and faster server. It may well be that you can buy enough hardware for pgsql to outrun a similarly priced RAC setup. Counting how much oracle charges per machine in a RAC cluster, it's not unreasonable to think so. RAC isn't infused with magic pixie dust, there's a point at which adding machines to a RAC cluster will no longer make the cluster faster. The SAN required for a RAC cluster is not cheap. BTW, I assume you're talking about a transactional db, i.e. banking type transactions. > I know after reading your post that Postgres cannot match RAC. I'm still not > sure if Postgres can operate a database from more than one box, at all. There's been some work going on that I've seen mentioned to give PostgreSQL a RAC like capability, but I don't think we'll see it real soon. for now, postgresql does single master multuple slave asynchronous replication quite well. multi-master synchronous, which is what RAC basically does is not available. It it quite possible that as hardware and pgsql get faster that all the scaling you'll need can be provided by those two things. How many transactions per second are you planning on? Can you partition your data to multiple servers? > PGCluster on PGFoundry seems to be more about replication. I'm not all that familiar with pgcluster. ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match