| From: | Darafei "Komяpa" Praliaskouski <me(at)komzpa(dot)net> |
|---|---|
| To: | Nikolay Samokhvalov <nik(at)postgres(dot)ai> |
| Cc: | pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Kirk Wolak <wolakk(at)gmail(dot)com>, Andrey Borodin <amborodin(at)acm(dot)org>, aekorotkov(at)gmail(dot)com |
| Subject: | Re: Missing wait events (gap analysis) |
| Date: | 2025-11-23 10:28:19 |
| Message-ID: | CAC8Q8tJ_w0wgJ6EpZLE_eWKMHqamoc-7rsEbk0YiO4hM7u9dvg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hello,
On Sat, Nov 22, 2025 at 4:43 AM Nikolay Samokhvalov <nik(at)postgres(dot)ai> wrote:
> Hi hi
>
> Many 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.md
>
> Before 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.
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Álvaro Herrera | 2025-11-23 12:14:37 | Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY |
| Previous Message | Darafei Komяpa Praliaskouski | 2025-11-23 10:07:50 | Re: pg_utility ? |