From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Greg Stark <stark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: patch: improve SLRU replacement algorithm |
Date: | 2012-04-04 20:34:21 |
Message-ID: | CA+U5nM+3qXwfJaRdRyFXWvvF4t151-BJY5cq5jWgGOSFdeviRg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Apr 4, 2012 at 9:05 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Yes, the SLRU is thrashing heavily. In this configuration, there are
> 32 CLOG buffers. I just added an elog() every time we replace a
> buffer. Here's a sample of how often that's firing, by second, on
> this test (pgbench with 32 clients):
Interesting. You've spoken at length how this hardly ever happens and
so this can't have any performance effect. That was the reason for
kicking out my patch addressing clog history, wasn't it?
Why is this pgbench run accessing so much unhinted data that is > 1
million transactions old? Do you believe those numbers? Looks weird.
Perhaps we should retest the clog history patch?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Euler Taveira | 2012-04-04 20:50:05 | Re: postgres long options without value |
Previous Message | Simon Riggs | 2012-04-04 20:25:27 | Re: patch: improve SLRU replacement algorithm |