Re: More info on pg_stat_activity Wait Event Name when is DataFileRead - Mailing list pgsql-hackers

From Robert Haas
Subject Re: More info on pg_stat_activity Wait Event Name when is DataFileRead
Date
Msg-id CA+TgmoYZC5S6LLi+GfMtEUYKU25iDXMR=DHa9m2Zd4R7QxWQeg@mail.gmail.com
Whole thread Raw
In response to More info on pg_stat_activity Wait Event Name when is DataFileRead  (PegoraroF10 <marcos@f10.com.br>)
Responses Re: More info on pg_stat_activity Wait Event Name when is DataFileRead
List pgsql-hackers
On Sat, Apr 17, 2021 at 1:58 PM PegoraroF10 <marcos@f10.com.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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: SQL-standard function body
Next
From: Tom Lane
Date:
Subject: Re: Planning time grows exponentially with levels of nested views