| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Greg Stark <stark(at)mit(dot)edu>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: measuring lwlock-related latency spikes |
| Date: | 2012-04-02 21:25:46 |
| Message-ID: | 4ED52620-A70B-49DF-8B16-C3F753AE2633@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Apr 2, 2012, at 3:04 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Seems like basically what you've proven is that this code path *is* a
> performance issue, and that we need to think a bit harder about how to
> avoid doing the fsync while holding locks.
Hmm, good idea. I wonder if we couldn't just hand off the fsync request to the background writer, as we do with buffer fsync requests. AFAICS we don't need the fsync to happen right away; the next checkpoint cycle should be soon enough.
...Robert
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2012-04-02 21:27:56 | Re: measuring lwlock-related latency spikes |
| Previous Message | Jeff Janes | 2012-04-02 21:13:00 | Re: measuring lwlock-related latency spikes |