Re: [HACKERS] wait events for disk I/O
От | Amit Kapila |
---|---|
Тема | Re: [HACKERS] wait events for disk I/O |
Дата | |
Msg-id | CAA4eK1KDs+AD8-h=nX-Ht+yv66OJU1jc5ZeWcby9MxSbPKDrFw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] wait events for disk I/O (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] wait events for disk I/O
|
Список | pgsql-hackers |
On Tue, Mar 7, 2017 at 5:27 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Mon, Mar 6, 2017 at 3:27 AM, Rushabh Lathia <rushabh.lathia@gmail.com> wrote: >> Yes, I thought of adding wait event only for the sync but then recording the >> wait event for both write and sync. I understand that OS level writes are >> cheap but it still have some cost attached to that. Also I thought for the >> monitoring tool being develop using this wait events, will have more useful >> capture data if we try to collect as much info as we can. Or may be not. >> >> I am open for other opinion/suggestions. > > Writes are NOT always fast. I've seen cases of write() blocking for > LONG periods of time on systems that are in the process of failing, or > just busy. So I think we certainly want to advertise a wait event for > those. > Sure, if you think both Writes and Reads at OS level can have some chance of blocking in obscure cases, then we should add a wait event for them. > Likewise, I agree that the prefetch call probably SHOULDN'T block, but > just because it shouldn't doesn't mean it never will. > > I think somebody should try a pgbench run with this patch applied, > using a scale factor greater than shared_buffers, and generate a wait > event profile, just to see if these are showing up and how often. > Yeah, that makes sense to me and we should try for both read-write and read-only tests. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: