[no cc:s please]
On Mon, 2003-01-20 at 10:31, Daniel Kalchev wrote:
> >>>"D'Arcy J.M. Cain" said:
> > On Thursday 16 January 2003 11:59, Adrian 'Dagurashibanipal' von Bidder wrot
> e:
> > > On Thu, 2003-01-16 at 17:42, D'Arcy J.M. Cain wrote:
> > > > 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?
> > >
> > > At most one CPU is used for any single postgres backend (that means for
> > > any single database connection). So, if your load problem is single
> > > queries being too slow, thee's nothing you can do with adding more CPUs.
> > > If your problem is many connections maxing out the db, PostgreSQL can
> > > take full advantage of multiple CPUs.
> >
> > I most definitely have multiple queries running at once. My main issue is
> > whether PostgreSQL scales up properly or does it get bogged down with too
> > many locked queries.
>
> That would depend on the OS. Not many 'pc-based unix' support over 4 GB of
> memory, some don't even go that far.
> By the way, I too wonder which supported OS platform would support over 4GB of
> memory on a PC..
Linux? I don't think there's any problem handling more than 4G memory in
the system. On 32bit architectures, there's of course the 3G (I think)
per process limit, but as postgres uses multiprocess and not
multithreading, this issue doesn't hit so soon. Of course, if the per
process memory is the problem, you'd have to go to 64bit.
cheers
-- vbi
--
featured link: http://fortytwo.ch/gpg/intro
