On Tue, 2003-09-02 at 11:01, Vivek Khera wrote:
> >>>>> "AS" == Andrew Sullivan <[EMAIL PROTECTED]> writes:
>
> AS> On Fri, Aug 29, 2003 at 12:05:03AM -0700, William Yu wrote:
> >> We should see a boost when we move to 64-bit Linux and hopefully another
> >> one when NUMA for Linux is production-stable.
>
> AS> According to the people who've worked with SGIs, NUMA actually seems
> AS> to make things worse. It has something to do with how the shared
> AS> memory is handled. You'll want to dig through the -general or
> AS> -hackers archives from somewhere between 9 and 14 months ago, IIRC.
>
> I knew my PhD research would one day be good for *something* ...
>
> The basic premise of NUMA is that you can isolate which data belongs
> to which processor and put that on memory pages that are local/closer
> to it. In practice, this is harder than it sounds as it requires very
> detailed knowledge of the application's data access patterns, and how
> memory is allocated by the OS and standard libraries. Often you end
> up with pages that have data that should be local to two different
> processors, and that data keeps being migrated (if your NUMA OS
> supports page migration) between the two processors or one of them
> just gets slow access.
>
> I can't imagine it benefiting postgres given its globally shared
> buffers.
Opteron is supposed to have screaming fast inter-CPU memory xfer
(HyperTransport does inter-CPU as well as well as CPU-RAM transport).
That's supposed to help with scaling, and PostgreSQL really may take
advantage of that, with, say 16-32 processors?
--
-----------------------------------------------------------------
Ron Johnson, Jr. [EMAIL PROTECTED]
Jefferson, LA USA
"Knowledge should be free for all."
Harcourt Fenton Mudd, Star Trek:TOS, "I, Mudd"
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
