Re: Missing wait events (gap analysis)
| От | Darafei "Komяpa" Praliaskouski |
|---|---|
| Тема | Re: Missing wait events (gap analysis) |
| Дата | |
| Msg-id | CAC8Q8tJ_w0wgJ6EpZLE_eWKMHqamoc-7rsEbk0YiO4hM7u9dvg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Missing wait events (gap analysis) (Nikolay Samokhvalov <nik@postgres.ai>) |
| Ответы |
Re: Missing wait events (gap analysis)
|
| Список | pgsql-hackers |
Hi hiMany tools that implement wait event analysis, when visualizing samples with "wait_event is null" use green color and "CPU" (perhaps, it started with RDS Performance Insights and PASH Viewer and, I suppose, originally came from the Oracle world, and now I see it in many more places).I don't have any concerns with green color, but always had a feeling that "coalesce(wait_event, 'CPU')" is an assumption that can make analysis inaccurate, because there may be a lot of places in the code that are not covered by wait events, but technically should -- and such places cannot be named "CPU".I asked Claude Code to analyze Postgres source code and find such places, that we could potentially cover with more wait events. Here is the first result: https://github.com/NikolayS/postgres/blob/claude/cpu-asterisk-wait-events-01CyiYYMMcFMovuqPqLNcp8T/WAIT_EVENTS_ANALYSIS.mdBefore moving forward with proposals of specific patches, I wanted to hear opinions -- does it make sense to work in this direction?
Definitely will make sense to have more insights into wait for the other side of the COPY pipe, TOAST compression.
Other spots that may be invisible but helpful to keep track of are serialization/deserialization that happens on IN/OUT functions (so many surprises when EXPLAIN ANALYZE doesn't account for time to actually serialize the output for large PostGIS geometries! and that stuff like timestamptz in is also surprisingly slow), and when passing stuff around between parallel workers.
В списке pgsql-hackers по дате отправления: