Re: measuring lwlock-related latency spikes
От | Tom Lane |
---|---|
Тема | Re: measuring lwlock-related latency spikes |
Дата | |
Msg-id | 10670.1333393454@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: measuring lwlock-related latency spikes (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: measuring lwlock-related latency spikes
Re: measuring lwlock-related latency spikes Re: measuring lwlock-related latency spikes |
Список | pgsql-hackers |
Robert Haas <robertmhaas@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. regards, tom lane
В списке pgsql-hackers по дате отправления: