Re: prelimiary performance comparison pgsql vs mysql - Mailing list pgsql-general

From Doug McNaught
Subject Re: prelimiary performance comparison pgsql vs mysql
Date
Msg-id 878y4noe7t.fsf@asmodeus.mcnaught.org
Whole thread Raw
In response to Re: prelimiary performance comparison pgsql vs mysql  ("Joshua D. Drake" <jd@commandprompt.com>)
List pgsql-general
"Joshua D. Drake" <jd@commandprompt.com> writes:

>> Also, a 32-bit machine can only hold so much RAM. If I'm correct, there
>> are ways to address more memory than that on a 32 bit machine, but I
>> wonder at what cost? In other words, is it a good idea to address more
>> than 4GB on a 32 bit machine? If not, is it a reasonable choice to
>> invest in 64 bit if you want >4GB of RAM? Or are you better off just
>> spending the money on RAID and staying at 4GB?
>
> It entirely depends on the database but not that the 32bit limit of 4GB
> is per CPU. So if you have 4 CPUs you can have 16GB of ram.

It's actually per-process, not per-CPU.  The x86 ISA only has 32-bit
address registers, so a process can only "see" 4GB max.  The PAE
extensions that came in with the PPro allow for more address bits in
the page tables, so each process sees a different subset of a larger
pool of physical RAM.

The implication of this for PostgreSQL on x86 is that each backend has
a maximum of 4GB (actually, usually more like 3 to allow for kernel
address space) that must include shared buffers, server code and data,
and memory used for sorting etc.

On 64-bit platforms, the 4GB address space limitation disappears, and
a single backend could use 20GB for a sort, if the memory was
available and the administrator allowed it.

> However, you should be running Opterons anyway.

Yup.  :)

-Doug

pgsql-general by date:

Previous
From: "FERREIRA William (COFRAMI)"
Date:
Subject: plPerl subroutine
Next
From: Miroslav Šulc
Date:
Subject: psql file restore - problem with encoding