Re: Page replacement algorithm in buffer cache - Mailing list pgsql-hackers

From Ants Aasma
Subject Re: Page replacement algorithm in buffer cache
Date
Msg-id CA+CSw_tHoPr8p0HDBOOCvJeNV7n1AgQMFP8zG=T_5MYbWOKVmw@mail.gmail.com
Whole thread Raw
In response to Re: Page replacement algorithm in buffer cache  (Jim Nasby <jim@nasby.net>)
Responses Re: Page replacement algorithm in buffer cache  (Jim Nasby <jim@nasby.net>)
List pgsql-hackers
On Sat, Mar 23, 2013 at 6:04 AM, Jim Nasby <jim@nasby.net> wrote:
> Partitioned clock sweep strikes me as a bad idea... you could certainly get
> unlucky and end up with a lot of hot stuff in one partition.

Surely that is not worse than having everything in a single partition.
Given a decent partitioning function it's very highly unlikely to have
more than a few of the hottest buffers end up in a single partition.

> Another idea that'sbeen broughht up inthe past is to have something in the
> background keep a minimum number of buffers on the free list. That's how OS
> VM systems I'm familiar with work, so there's precedent for it.
>
> I recall there were at least some theoretical concerns about this, but I
> don't remember if anyone actually tested the idea.

Yes, having bgwriter do the actual cleaning up seems like a good idea.
The whole bgwriter infrastructure will need some serious tuning. There
are many things that could be shifted to background if we knew it
could keep up, like hint bit setting on dirty buffers being flushed
out. But again, we have the issue of having good tests to see where
the changes hurt.

Regards,
Ants Aasma
--
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de



pgsql-hackers by date:

Previous
From: Ants Aasma
Date:
Subject: Re: Page replacement algorithm in buffer cache
Next
From: Ants Aasma
Date:
Subject: Re: Enabling Checksums