Re: Page replacement algorithm in buffer cache

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Jim Nasby <jim(at)nasby(dot)net>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Ants Aasma <ants(at)cybertec(dot)at>, Atri Sharma <atri(dot)jiit(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila(at)huawei(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Page replacement algorithm in buffer cache
Date: 2013-04-04 00:41:39
Message-ID: 29209.1365036099@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Stark <stark(at)mit(dot)edu> writes:
> I'm still skeptical about the idea of a "freelist". That just seems like a
> terrible point of contention. However perhaps that's because I'm picturing
> an LRU linked list. Perhaps the right thing is to maintain a pool of
> buffers in some less contention-prone data structure which lets each
> backend pick buffers out more or less independently of the others.

I think the original vision of the clock sweep algorithm included the
idea that different backends could be running the sweep over different
parts of the buffer ring concurrently. If we could get rid of the need
to serialize that activity, it'd pretty much eliminate the bottleneck
I should think. The problem is how to manage it to ensure that (a)
backends aren't actually contending on the same buffers as they do this,
and (b) there's a reasonably fair rate of usage_count decrements for
each buffer, rather than possibly everybody ganging up on the same area
sometimes. Thoughts?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-04-04 00:45:51 Re: corrupt pages detected by enabling checksums
Previous Message Andres Freund 2013-04-04 00:39:25 Re: corrupt pages detected by enabling checksums