Re: FreeBSD: SMP and PostgreSQL - Mailing list pgsql-general

From Chris Johnson
Subject Re: FreeBSD: SMP and PostgreSQL
Date
Msg-id 3E433C55.9040701@chaska.com
Whole thread Raw
In response to Re: FreeBSD: SMP and PostgreSQL  (Mitch <postgresql@karboneye.com>)
Responses Re: FreeBSD: SMP and PostgreSQL
List pgsql-general
Mitch wrote:
> I've been playing with PG on a new FreeBSD 5.0 SMP box and I can't say
> the performance is dramatic, but I haven't done serious benchmarking
> yet. I will post the results if there is a gigantic leap..

> On Thursday, February 6, 2003, at 02:21  PM, Vivek Khera wrote:

>>>>>>>"RAD" == Ruslan A Dautkhanov <rusland@scn.ru> writes:
>>RAD>  Old releases (4.7, for example) also supports SMP, but worse
>>RAD>  comparative with version 5 as described in above mentioned
>>RAD>  release notes. Please say, if anybody test SMP in FreeBSD for
>>RAD>  PostgreSQL - really Postgres with v5.0 will "dramatically"
>>RAD>  increase SQL server performance?
>>
>>I run Postgres 7.2 on FreeBSD 4.7 with dual procs.  Works fine.  I
>>will wait until about FreeBSD 5.2 before I upgrade this server.

FreeBSD prior to 5.0 does not do SMP within a single process, i.e.
light-weight threads like SunOS/Solaris.  However, this is almost
irrelevant with respect to PostgreSQL, since each connection to
PostgreSQL gets its own process.  Thus, multi-CPUs on FreeBSD 4.x will
run the multiple PostgreSQL processes just in an SMP manner just fine.

Well, almost.  SMP really means Symmetric Multi-Processing, not just
multiprocessors, and the FreeBSD 4.x kernel is not multi-threaded, so
during system calls, all processes are single threaded through the kernel.

FreeBSD 5.0 changes this and allows most, but not all, of the kernel to
be multi-threaded.

So to the extent that your performance is limited by kernel "bandwidth"
moving to FreeBSD 5.x will help.  Chances are you'll be disk IO limited
long before you get kernel limited, though.


pgsql-general by date:

Previous
From: Neil Conway
Date:
Subject: Re: immediate if function
Next
From: John Smith
Date:
Subject: selects with large offset really slow