Message-ID: <514EFB8A.80306@2ndQuadrant.com>
Date: Sun, 24 Mar 2013 09:11:38 -0400
From: Greg Smith <greg@2ndQuadrant.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: Re: Page replacement algorithm in buffer cache
References: 
 <CAOeZVic4HikhmzVD=ZP4JY9g8PgpyiQQOXOELWP=kR+=H1Frgg@mail.gmail.com>
	<514bf302.84d5440a.43f2.ffffe411SMTPIN_ADDED_BROKEN@mx.google.com>
	<08BBC126-D375-4743-B9A6-D1320D05D5C7@gmail.com>
	<514c3395.487a420a.28d1.764eSMTPIN_ADDED_BROKEN@mx.google.com>
	<CAOeZVifZ89tOtcKeC6C2917sVfSyR3xiMenorg8sNR2+y2W=Wg@mail.gmail.com>
	<CA+CSw_se74iDCLswBfF7_Rd1542nhyw-YSmQ+OqDwEzu0rZkSw@mail.gmail.com>
In-Reply-To: 
 <CA+CSw_se74iDCLswBfF7_Rd1542nhyw-YSmQ+OqDwEzu0rZkSw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 3/22/13 8:45 AM, Ants Aasma wrote:
> However, I think the main issue isn't finding new algorithms that are
> better in some specific circumstances. The hard part is figuring out
> whether their performance is better in general.

Right.  The current page replacement method works as expected.  Many 
frequently accessed pages accumulate a usage count of 5 before the clock 
sweep hits them.  Pages that are accessed once and not again before the 
clock sweep are evicted.  There are several theoretically better ways to 
approach this.  Anyone who hasn't already been working on this for a few 
years is very unlikely to come up with a brand new idea, one that hasn't 
already been tested in the academic research.

But the real blocker here isn't ideas, it's creating benchmark workloads 
to validate any change.  Right now I see the most promising work that 
could lead toward the "performance farm" idea as all of the Jenkins 
based testing that's been going on recently.  Craig Ringer has using 
that for 2ndQuadrant work here, Peter Eisentraut has been working with 
it: 
http://petereisentraut.blogspot.com/2013/01/postgresql-and-jenkins.html 
and the PostGIS project uses it too.  There's some good momentum brewing 
there.

When we have regular performance testing with a mix of workloads--I have 
about 10 in mind to start--at that point we could start the testing 
performance changes to the buffer replacement.  Until then this whole 
area is hard to touch usefully.  You have to assume that any tuning you 
do for one type of workload might accidentally slow another.  Starting 
with a lot of baseline workloads is the only way to move usefully 
forward when facing that problem.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers