Re: [PERFORM] utilising multi-cpu/core machines?

2007-09-07 Thread Sven Geisler
Hi Thomas,

PostgreSQL does scale up very well. But you have to keep in mind that
this also depends on profile of the application you're on PostgreSQL.

Insufficient memory and slow disk systems can interfere PostgreSQL.
Another issue is contention if the server has more than 4 cpus.
(Please check out discussions about context strom in this group.)

Anyhow, I had create a benchmark for my company which shows the scale up
of PostgreSQL 8.1.4. This benchmark does try to enforce contention
because of the profile of our application.

Clients/scale-up factor
1   1
2   1,78
3   2,47
4   3,12
5   3,62
6   4,23
7   4,35
8   4,79
9   5,05
10  5,17

Scale-up factor is relative to one client the number of completed
queries in a time frame. (throughput)

This test was done on a 16 core Intel-box (4-way Xeon E7340).

The results of TPC-B benchmark are looking similar.

Sven.


Thomas Finneid schrieb:
 Hi
 
 I couldnt find any specifics on this subject in the documentation, so I
 thought I'd ask the group.
 
 how does pg utilise multi cpus/cores, i.e. does it use more than one
 core? and possibly, how, are there any documentation about this.
 
 thomas
 
 ---(end of broadcast)---
 TIP 6: explain analyze is your friend

-- 
Sven Geisler [EMAIL PROTECTED]   Tel +49.30.921017.81  Fax .50
Senior Developer, AEC/communications GmbH  Co. KG Berlin, Germany

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


Re: [PERFORM] utilising multi-cpu/core machines?

2007-09-06 Thread Kevin Grittner
 On Wed, Sep 5, 2007 at  5:41 PM, in message [EMAIL PROTECTED],
Thomas Finneid [EMAIL PROTECTED] wrote: 
 how does pg utilise multi cpus/cores, i.e. does it use more than one 
 core? and possibly, how, are there any documentation about this.
 
For portability reasons PostgreSQL doesn't use threads, per se, but spawns
a new process for each connection, and a few for other purposes.  Each
process may be running on a separate CPU, but a single connection will
only be using one -- directly, anyway.  (The OS may well be using the
other for I/O, etc.)
 
For documentation, you could start with this:
 
http://www.postgresql.org/docs/8.2/interactive/app-postgres.html
 
-Kevin
 



---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


[PERFORM] utilising multi-cpu/core machines?

2007-09-05 Thread Thomas Finneid

Hi

I couldnt find any specifics on this subject in the documentation, so I 
thought I'd ask the group.


how does pg utilise multi cpus/cores, i.e. does it use more than one 
core? and possibly, how, are there any documentation about this.


thomas

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [PERFORM] utilising multi-cpu/core machines?

2007-09-05 Thread Jonah H. Harris
On 9/5/07, Thomas Finneid [EMAIL PROTECTED] wrote:
 how does pg utilise multi cpus/cores, i.e. does it use more than one
 core? and possibly, how, are there any documentation about this.

Unlike other systems which manage their own affinity and
prioritization, Postgres relies solely on the OS to handle process
management across multiple CPUs/cores.

-- 
Jonah H. Harris, Software Architect | phone: 732.331.1324
EnterpriseDB Corporation| fax: 732.331.1301
33 Wood Ave S, 3rd Floor| [EMAIL PROTECTED]
Iselin, New Jersey 08830| http://www.enterprisedb.com/

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [PERFORM] utilising multi-cpu/core machines?

2007-09-05 Thread Trevor Talbot
On 9/5/07, Thomas Finneid [EMAIL PROTECTED] wrote:

 how does pg utilise multi cpus/cores, i.e. does it use more than one
 core? and possibly, how, are there any documentation about this.

PostgreSQL creates a new process to handle each connection to the
database.  Multiple sessions can therefore spread across multiple
cores, but a single session will never use more than one.

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org