Re: Background LRU Writer/free list - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Background LRU Writer/free list
Date
Msg-id 87hcrdpmfg.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Background LRU Writer/free list  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Background LRU Writer/free list
List pgsql-hackers
"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> Why?  What you're really trying to determine, I think, is the I/O load
> imposed by the bgwriter, and pages-per-second seems a pretty natural
> way to think about that; percentage of shared buffers not so much.

What I'm saying is that pages/s will vary from system to system. Busier
systems will have higher i/o rates. So a system with a DBA on a system with a
higher rate will want to adjust the bgwriter sleep time lower than the DBA on
a system where bgwriter isn't doing much work.

In particular I'm worried about what happens on a very busy cpu-bound system
where adjusting the sleep times would result in it deciding to not sleep at
all. On such a system sleeping for even 10ms might be too long. But we
probably don't want to make the default even as low as 10ms.

Anyways, if we have a working patch that works the other way around we could
experiment with that and see if there are actual situations where sleeping for
0ms is necessary. Perhaps a mixture of the two approaches will be necessary
anyways because of the granularity issue.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Can't ri_KeysEqual() consider two nulls as equal?
Next
From: Martin Langhoff
Date:
Subject: Re: Hacking on PostgreSQL via GIT