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

Re: Bgwriter LRU cleaning: we've been going at this all wrong

From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
To: Greg Smith <gsmith(at)gregsmith(dot)com>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Bgwriter LRU cleaning: we've been going at this all wrong
Date: 2007-06-26 22:58:36
Message-ID: 46819A1C.1020801@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Greg Smith wrote:
> I broke Itagaki-san's patch into two pieces when I was doing the review 
> cleanup on it specifically to make it easier to tinker with this part 
> without losing some of its other neat features.  Heikki, did you do 
> anything with that LRU adjustment patch since I sent it out: 
> http://archives.postgresql.org/pgsql-patches/2007-05/msg00142.php

I like the idea of breaking down the patch into two parts, though I 
didn't like the bitmasked return code stuff in that first patch.

I haven't worked on that patch. I started looking at this, using 
Itagaki's patch as the basis. In fact, as Tom posted his radical idea, I 
was writing down my thoughts on the bgwriter patch:

I think regardless of the details of how bgwriter should work, the
design is going have three parts:

Part 1: Keeping track of how many buffers have been requested by
backends since last bgwriter round.

Part 2: An algorithm to turn that number into desired # of clean buffers
we should have in front of the clock hand. That could include storing
some historic data to use in the calculation.

Part 3: A way to check that we have that many clean buffers in front of
the clock hand. We might not do that exactly, an approximation would be
enough.

Itagaki's patch attached implements part 1 in the obvious way. A trivial 
implementation for part 2 is (desired # of clean buffers) = (buffers
requested since last round). For part 3, we start from current clock 
hand and scan until we've seen/cleaned enough unpinned buffers with 
usage_count = 0, or until we reach bgwriter_lru_percent.

I think we're good with part 1, but I'm sure everyone has their 
favourite idea for 2 and 3. Let's hear them now.

> Unless someone else has a burning desire to implement Tom's idea faster 
> than me, I should be to build this new implementation myself in the next 
> couple of days.  I still have the test environment leftover from the 
> last time I worked on this code, and I think everybody else who could 
> handle this job has more important higher-level things they could be 
> working on instead.

Oh, that would be great! Since you have the test environment ready, can 
you try alternative patches as well as they're proposed?

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

In response to

Responses

pgsql-hackers by date

Next:From: Bruce McAlisterDate: 2007-06-26 23:01:06
Subject: Re: AutoVacuum Behaviour Question
Previous:From: Heikki LinnakangasDate: 2007-06-26 22:40:29
Subject: Re: Bgwriter LRU cleaning: we've been going at this all wrong

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