Re: SMP scaling

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Mark Rae <mrae(at)purplebat(dot)com>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, postgres list <pgsql-general(at)postgresql(dot)org>
Subject: Re: SMP scaling
Date: 2005-03-19 04:04:06
Message-ID: 12314.1111205046@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Mark Rae <mrae(at)purplebat(dot)com> writes:
> Even with the numa support, which makes sure any memory allocated by
> malloc or the stack ends up local to the processor which originally
> called it, and then continues to schedule the process on that CPU,
> there is still the problem that all table accesses* go through
> the shared buffer cache which resides in one location.
> [* is this true in all cases?]

Temp tables are handled in backend-local memory, but all normal tables
have to be accessed through shared buffers. The implications of not
doing that are bad enough that it's hard to believe it could be a win
to change. (In short: the hardware may not like syncing across
processors, but it can still do it faster than we could hope to do in
software.)

> it looks like SGI already have a solution in the form of
> symmetric data objects.
> In particular, the symmetric heap, an area of shared memory
> which is replicated across all memory domains with the
> coherency being handled in hardware.

Hmm, do they support spinlock objects in this memory? If so it could be
just the right thing.

> So it looks like all that might be needed is to replace the
> shmget calls in src/backend/port with the equivalent SGI functions.

Send a patch ;-)

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Phil Daintree 2005-03-19 05:03:35 Re: Query performance problem
Previous Message Paul Tillotson 2005-03-19 01:48:35 Re: Query performance problem