Re: Scalability Design Questions

Yes the trx would be akin to banking operations.

This is good: "Can you partition your data to multiple servers?" That's kind
of my question! <g> I've not dealt with RAC, data partitioning, any of those
topics; just haven't had exposure. But since you're asking me if the data
can be partitioned to different servers, it must mean that at least under
some cirucumstances, postgres can do this. If you or anyone can tell me more
about that or point me to some resources, it'd be great.

Thanks for the info

Scott Marlowe-2 wrote:
>
> On 9/8/07, novnov <novnovice(at)gmail(dot)com> 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
>
>

--
View this message in context: http://www.nabble.com/Scalability-Design-Questions-tf4406693.html#a12573403
Sent from the PostgreSQL - general mailing list archive at Nabble.com.