| From: | "Ryo Matsumura (Fujitsu)" <matsumura(dot)ryo(at)fujitsu(dot)com> |
|---|---|
| To: | Hironobu SUZUKI <hironobu(at)interdb(dot)jp>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [PATCH] Reduce EXPLAIN ANALYZE overhead for row counting |
| Date: | 2026-03-11 09:08:32 |
| Message-ID: | TYRPR01MB13457E2998F52D94C51422AFDE847A@TYRPR01MB13457.jpnprd01.prod.outlook.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Suzuki-san, hackers,
I am supportive of efforts to improve EXPLAIN ANALYZE.
At a minimum, I would like to see the Phase 1 patch merged.
I have reviewed only the Phase 1 patch, and I did not notice any problems with it.
It's very simple.
In practice, when we encounter performance issues in customer systems, it is often not feasible to ask them to run EXPLAIN ANALYZE on the live production system with the real application workload. The overhead can be high enough to risk destabilizing the system.
While fully resolving a performance issue may ultimately require enabling BUFFERS, TIMING, and WAL, the small overhead demonstrated here makes focusing only on row counting a very reasonable first step. In some cases, if the issue is primarily related to the execution plan itself, this information alone may be sufficient to identify the problem.
From that perspective, I believe customers would be much more willing to accept running EXPLAIN ANALYZE with this reduced overhead.
Thanks for working on this.
Just my perspective based on support experience with customer systems.
Best Regards
Ryo Matsumura
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Lukas Fittl | 2026-03-11 09:11:17 | Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? |
| Previous Message | shveta malik | 2026-03-11 08:45:19 | Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication |