Re: [HACKERS] wait events for disk I/O - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] wait events for disk I/O
Date
Msg-id CA+TgmoZXGO2Rg-XLeeT7ECYUtrAz0sU-5qEVM5Cg3C6f3yeUEw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] wait events for disk I/O  (Rushabh Lathia <rushabh.lathia@gmail.com>)
Responses Re: [HACKERS] wait events for disk I/O  (Michael Paquier <michael.paquier@gmail.com>)
Re: [HACKERS] wait events for disk I/O  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
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.

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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] contrib modules and relkind check
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Performance degradation in TPC-H Q18