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

Re: I/O on select count(*)

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To: Matthew Wakeling <matthew(at)flymine(dot)org>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: I/O on select count(*)
Date: 2008-05-19 15:47:38
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Mon, 19 May 2008, Matthew Wakeling wrote:

> Does it really take that long to zero out 8kB of RAM? I thought CPUs were 
> really quick at doing that!

You don't get the whole CPU--you get time slices of one.  Some of the 
cases complaints have come in about have over a thousand connections all 
fighting for CPU time, and making every one of them block for one guy who 
needs to fiddle with memory for a while can be a problem.  If you're 
unlucky you won't even be on the same CPU you started on each time you get 
a little check of time, and you'll run at the speed of RAM rather than 
that of the CPU--again, fighting for RAM access with every other process 
on the server.

The real question in my mind is why this turns into a bottleneck before 
the similar task of cleaning the 16MB XLOG segment does.  I expected that 
one would need to be cracked before the CLOG switch time could possibly be 
an issue, but reports from the field seem to suggest otherwise.

* Greg Smith gsmith(at)gregsmith(dot)com Baltimore, MD

In response to


pgsql-performance by date

Next:From: Tom LaneDate: 2008-05-19 15:53:49
Subject: Re: I/O on select count(*)
Previous:From: Tom LaneDate: 2008-05-19 15:37:58
Subject: Re: I/O on select count(*)

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