From: | Neil Conway <neilc(at)samurai(dot)com> |
---|---|
To: | "D'Arcy J(dot)M(dot) Cain" <darcy(at)druid(dot)net> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Options for growth |
Date: | 2003-01-16 17:23:52 |
Message-ID: | 1042737832.20007.55.camel@tokyo |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 2003-01-16 at 11:42, D'Arcy J.M. Cain wrote:
> Is [Oracle RAC] really as simple as it sounds or would we just be
> giving up the other two for a new set of problems.
That's a question you should be asking to an authority on Oracle RAC
(which pgsql-hackers is not).
> My idea is to create a new middleware layer that allows me to split things up
> based on various criteria without changing my application.
Personally, I would not be very eager to use home-brew replication for a
heavy-load, production-critical application (which is what your app
sounds like). But YMMV...
> We are also looking at hardware solutions, multi-CPU PCs with tons (24GB) of
> memory. I know that memory will improve access if it prevents swapping but
> how well does PostgreSQL utilize multiple CPUs?
The estimates I've heard from a couple parties are that PostgreSQL tends
to scale well up to 4 CPUs. I've been meaning to take a look at
improving that, but I haven't had a chance yet...
Another option is to put some money toward the current development
effort to get truly scalable replication for PostgreSQL. In the end, I'd
think the cost of subsidizing some of that development would be a
fraction of the license fees you'll end up paying Oracle over the
years...
Cheers,
Neil
--
Neil Conway <neilc(at)samurai(dot)com> || PGP Key ID: DB3C29FC
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Kalchev | 2003-01-16 18:41:33 | Re: Indexes |
Previous Message | Adrian 'Dagurashibanipal' von Bidder | 2003-01-16 16:59:19 | Re: Options for growth |