On Tue, Mar 7, 2017 at 5:27 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Mon, Mar 6, 2017 at 3:27 AM, Rushabh Lathia <rushabh.lat...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
