| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com> |
| Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, imai(dot)yoshikazu(at)fujitsu(dot)com, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "yoshikazu_i443(at)live(dot)jp" <yoshikazu_i443(at)live(dot)jp> |
| Subject: | Re: [Proposal] Add accumulated statistics for wait event |
| Date: | 2021-06-14 18:27:21 |
| Message-ID: | 20210614182721.425j3xvsiphoq6ty@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2021-06-14 16:10:32 +0200, Jehan-Guillaume de Rorthais wrote:
> In the patch in attachment, I tried to fix this by using kind of an internal
> hook for pgstat_report_wait_start and pgstat_report_wait_end. This allows to
> "instrument" wait events only when required, on the fly, dynamically.
That's *far worse*. You're adding an indirect function call. Which requires
loading a global variable and then a far call to a different function. You're
changing a path that's ~2 instructions with minimal dependencies (and no
branches (i.e. fully out of order executable) to something on the order of ~15
instructions with plenty dependencies and at least two branches (call, ret).
I doubt there's a path towards this feature without adding the necessary
infrastructure to hot-patch the code - which is obviously quite a
substantial project.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2021-06-14 18:31:59 | Re: [Proposal] Add accumulated statistics for wait event |
| Previous Message | Andrew Dunstan | 2021-06-14 17:50:26 | Re: Race condition in recovery? |