Re: More info on pg_stat_activity Wait Event Name when is DataFileRead

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: PegoraroF10 <marcos(at)f10(dot)com(dot)br>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: More info on pg_stat_activity Wait Event Name when is DataFileRead
Date: 2021-04-18 19:18:33
Message-ID: CA+TgmoYZC5S6LLi+GfMtEUYKU25iDXMR=DHa9m2Zd4R7QxWQeg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Apr 17, 2021 at 1:58 PM PegoraroF10 <marcos(at)f10(dot)com(dot)br> wrote:
> This long explaining was only to show, at least for me, that would be
> desirable to have an additional information when Postgres is waiting for a
> file. What if DataFileRead showing relfilenode it´s waiting for ?

I agree that this would be nice, but it's pretty much impossible to do
it without adding quite a bit more overhead than the current system
has. And it already has enough overhead to make Andres at least
slightly grumpy, though admittedly a lot of things have enough
overhead to make Andres grumpy, because he REALLY likes it when things
go fast. :-)

I suspect it's best to investigate problems like the one you're having
using a tool like strace, which can provide way more detail than we
could ever cram into a wait event, like the data actually read or
written, timestamps for every operation, etc. But I also kind of
wonder whether it really matters. If your system is getting stuck in a
DataFileRead event for a long period of time, and assuming that's for
real and not just some kind of reporting bug, it sounds a lot like you
have a bad disk or a severely overloaded I/O subsystem. Because what
else would lead to the system getting stuck inside read() for a long
time?

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-04-18 20:14:07 Re: Planning time grows exponentially with levels of nested views
Previous Message Tom Lane 2021-04-18 19:08:44 Re: SQL-standard function body