Re: Missing wait events (gap analysis)

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.

>

In response to

Browse pgsql-hackers by date

  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 ?