Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Sun Donated a Sun Fire T2000 to the PostgreSQL

From: Arjen van der Meijden <acmmailing(at)tweakers(dot)net>
To: David Roussel <pgsql-performance(at)diroussel(dot)xsmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, pgsql-performance(at)postgresql(dot)org
Subject: Re: [HACKERS] Sun Donated a Sun Fire T2000 to the PostgreSQL
Date: 2006-06-22 14:19:21
Message-ID: 449AA6E9.9050804@tweakers.net (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-performance
On 22-6-2006 15:03, David Roussel wrote:
> Sureky the 'perfect' line ought to be linear?  If the performance was 
> perfectly linear, then the 'pages generated' ought to be G times the 
> number (virtual) processors, where G is the gradient of the graph.  In 
> such a case the graph will go through the origin (o,o), but you graph 
> does not show this. 
> 
> I'm a bit confused, what is the 'perfect' supposed to be?

First of all, this graph has no origin. Its a bit difficult to test with 
less than one cpu.

Anyway, the line actually is linear and would've gone through the 
origin, if there was one. What I did was take the level of the 
'max'-line at 1 and then multiply it by 2, 4, 6 and 8. So if at 1 the 
level would've been 22000, the 2 would be 44000 and the 8 176000.

Please do notice the distance between 1 and 2 on the x-axis is the same 
as between 2 and 4, which makes the graph a bit harder to read.

Best regards,

Arjen

In response to

Responses

pgsql-performance by date

Next:From: Tom LaneDate: 2006-06-22 14:47:27
Subject: Re: Regarding ERROR: fmgr_info: function 2720768: cache lookup failed
Previous:From: Craig A. JamesDate: 2006-06-22 14:03:25
Subject: Re: [HACKERS] Sun Donated a Sun Fire T2000 to the PostgreSQL

pgsql-hackers by date

Next:From: Jonah H. HarrisDate: 2006-06-22 14:20:28
Subject: Re: vacuum, performance, and MVCC
Previous:From: Csaba NagyDate: 2006-06-22 14:09:19
Subject: Re: vacuum, performance, and MVCC

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group