On Mon, Apr 2, 2012 at 8:04 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> Long story short, when a CLOG-related stall happens, >> essentially all the time is being spent in this here section of code: > >> /* >> * If not part of Flush, need to fsync now. We assume this happens >> * infrequently enough that it's not a performance issue. >> */ >> if (!fdata) // fsync and close the file > > 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.
Agreed, though I think it means the fsync is happening on a filesystem that causes a full system fsync. That time is not normal. I suggest we optimise that by moving the dirty block into shared buffers and leaving it as dirty. That way we don't need to write or fsync at all and the bgwriter can pick up the pieces. So my earlier patch to get the bgwriter to clean the clog would be superfluous. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
