On Sun, Mar 24, 2013 at 6:11 AM, Greg Smith <greg@2ndquadrant.com> wrote:
> 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.
Wow! Jenkins based performance farm should be just what we want.
Can we add tests for lock contentions(as discussed above), so that we
can move to some actual diagnostics?
Regards,
Atri
--
Regards,
Atri
l'apprenant
