| From: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Adding wait events statistics |
| Date: | 2025-07-15 14:13:49 |
| Message-ID: | aHZiHZ8sSQdHpyM6@bdt-Laptop-13th-Gen-Intel-Core |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On Fri, Jul 11, 2025 at 11:59:39AM -0400, Andres Freund wrote:
> Hi,
>
> On 2025-07-10 08:21:56 +0000, Bertrand Drouvot wrote:
> > - Let's define a list of "cheap" and a list of "expensive" wait events
> > - Change the code path to increment counters only for the "expensive" ones
> > - Optimize the counter incrementation as much as possible
> >
> > Does that sound reasonable to you?
>
> That does seem like the minimum.
>
> Unfortunately I'm rather doubtful this provides enough value to be worth the
> cost. But I'm rather willing to be proven wrong.
>
I guess that would (among other things) depend of how many wait events would be
tracked. I'll do some study to measure the counters's impact on the wait events.
BTW, I started to do so by using (i.e adding) probes in pgstat_report_wait_start()
and pgstat_report_wait_end() (to produce something like the attached), and
I wonder if those probes could be added in the Built-in ones, what do you
think? (that's true that they could be added manually as I did but I'm not sure
about what "deserve" to be added in the Built=in list)).
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
| Attachment | Content-Type | Size |
|---|---|---|
| ebpf_wait_make_check-world.txt | text/plain | 79.8 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Kukushkin | 2025-07-15 14:48:05 | Re: query_id: jumble names of temp tables for better pg_stat_statement UX |
| Previous Message | Vitale, Anthony, Sony Music | 2025-07-15 13:58:17 | Question on any plans to use the Create Server/Create blink_ Mapping to provide Logical Replication Subscriptions the user/password in an encrypted manner |