Re: prelimiary performance comparison pgsql vs mysql
От | Doug McNaught |
---|---|
Тема | Re: prelimiary performance comparison pgsql vs mysql |
Дата | |
Msg-id | 878y4noe7t.fsf@asmodeus.mcnaught.org обсуждение исходный текст |
Ответ на | Re: prelimiary performance comparison pgsql vs mysql ("Joshua D. Drake" <jd@commandprompt.com>) |
Список | 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 по дате отправления: