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

Re: 8.0.X and the ARC patent

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: 8.0.X and the ARC patent
Date: 2005-03-05 18:03:17
Message-ID: 1110045797.6117.105.camel@localhost.localdomain (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, 2005-03-04 at 20:10 -0500, Greg Stark wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> 
> > Amdahl's Law tells me that looking at the checkpoints is the next best
> > action for tuning, since they add considerably to the average response
> > time. Looking at the oprofile for the run as a whole is missing out the
> > delayed transaction behaviour that occurs during checkpoints.
> 
> Even aside from the effect it has on average response time. I would point out
> that many applications are governed by the worst case more than the average
> throughput.
> 
> For a web server, for example (or any OLTP application in general), it doesn't
> matter if the database can handle x transactions/s on average. What matters is
> that 100% of the time the latency is below the actual rate of requests. If
> every 30m latency suddenly spikes up beyond that, even for only a minute, then
> it will fall behind in the requests. The user will effectively see a
> completely unresponsive web server.
> 
> So I would really urge you to focus your attention on the maximum latency
> figure. It's at least if not *more* important than the average throughput
> number.

Sorry Greg, clearly my English was poor. 

The checkpoints are the source of the peak latency on transactions, so
we are in complete agreement. 

> PS That's why I was pushing before for the idea that the server should try to
> spread the I/O from one checkpoint out over more or less the time interval
> between checkpoints. If it's been 30m since the last checkpoint then you have
> about 30m to do the I/O for this checkpoint. (Though I would suggest a safety
> factor of aiming to be finished within 50% of the time.)

I don't want to fix it before I know what the issue is.

Best Regards, Simon Riggs


In response to

Responses

pgsql-hackers by date

Next:From: Pavel StehuleDate: 2005-03-05 19:06:23
Subject: Re: Exception ERROR Code
Previous:From: AlexDate: 2005-03-05 17:56:16
Subject: Explicit Transaction Priority

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