Re: Options for growth

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

In response to

Responses

Browse pgsql-hackers by date

  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