| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Stark <stark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: patch: improve SLRU replacement algorithm |
| Date: | 2012-04-05 09:34:16 |
| Message-ID: | CA+U5nM+V1JbYUL2eBmL1q731fSPUWxJ0zj-d85=G=qg-FmhNaA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Apr 5, 2012 at 1:23 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> I don't think we're micro-optimizing, either. I don't consider
> avoiding a 10-second cessation of all database activity to be a
> micro-optimization even on a somewhat artificial benchmark.
Robert is not skewing the SLRU mechanism towards this case, he is
simply fixing something so gross that "bug" is the only word for it,
and that shows up clearly on this test. I'm happy that the fix
proposed has general utility without negative impact on other
workloads.
In general terms, I agree we shouldn't rely on pgbench as a general
workload, nor should we solely tune Postgres for throughput without
regard to response time. But that point is not relevant to this
specific issue.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2012-04-05 09:41:08 | Re: patch: improve SLRU replacement algorithm |
| Previous Message | Huchev | 2012-04-05 09:06:28 | Re: Faster compression, again |