Re: Missing wait events (gap analysis)
| От | Matthias van de Meent |
|---|---|
| Тема | Re: Missing wait events (gap analysis) |
| Дата | |
| Msg-id | CAEze2WjX1u9nkw4isTKJJ5ZY00CvNgRCAKbmPfK40DRgeKihaQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Missing wait events (gap analysis) (Nikolay Samokhvalov <nik@postgres.ai>) |
| Ответы |
Re: Missing wait events (gap analysis)
|
| Список | pgsql-hackers |
On Sat, 22 Nov 2025 at 01:43, Nikolay Samokhvalov <nik@postgres.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 assumptionthat can make analysis inaccurate, because there may be a lot of places in the code that are not covered by waitevents, but technically should -- and such places cannot be named "CPU". Then, isn't that an issue with the reporting tool(s)? > I asked Claude Code to analyze Postgres source code and find such places, that we could potentially cover with more waitevents. Here is the first result: https://github.com/NikolayS/postgres/blob/claude/cpu-asterisk-wait-events-01CyiYYMMcFMovuqPqLNcp8T/WAIT_EVENTS_ANALYSIS.md Did you review this yourself, and include only those places that are actually relevant for wait events? I'm not opposed to using AI systems for analysis, for understanding the code, or for finding issues, but posting tool output without you first understanding all the proposed changes is a recipe for wasting everyone's time. > Before moving forward with proposals of specific patches, I wanted to hear opinions -- does it make sense to work in thisdirection? I don't think it's a bad idea to add wait events in potential wait points in code. Kind regards, Matthias van de Meent Databricks (https://www.databricks.com)
В списке pgsql-hackers по дате отправления: