From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
---|---|
To: | "imai(dot)yoshikazu(at)fujitsu(dot)com" <imai(dot)yoshikazu(at)fujitsu(dot)com> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Imai Yoshikazu <yoshikazu_i443(at)live(dot)jp>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: [Proposal] Add accumulated statistics for wait event |
Date: | 2020-02-12 05:42:20 |
Message-ID: | CAMsr+YE1vSOgt4WO9-igpiaR=QSpm1piuWcPHUmr6ormB4cfUA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 12 Feb 2020 at 12:36, imai(dot)yoshikazu(at)fujitsu(dot)com
<imai(dot)yoshikazu(at)fujitsu(dot)com> wrote:
> It seems performance difference is big in case of read only tests. The reason is that write time is relatively longer than the
> processing time of the logic I added in the patch.
That's going to be a pretty difficult performance hit to justify.
Can we buffer collected wait events locally and spit the buffer to the
stats collector at convenient moments? We can use a limited buffer
size with an overflow flag, so we degrade the results rather than
falling over or forcing excessive stats reporting at inappropriate
times.
I suggest that this is also a good opportunity to add some more
tracepoints to PostgreSQL. The wait events facilities are not very
traceable right now. Exposing some better TRACE_POSTGRESQL_
tracepoints (SDTs) via probes.d would help users collect better
information using external tools like perf, bpftrace and systemtap.
That way we have a zero-overhead-when-unused option that can also be
used to aggregate the information per-query, per-user, etc.
(I really need to add a bunch more tracepoints to make this easier...)
--
Craig Ringer http://www.2ndQuadrant.com/
2ndQuadrant - PostgreSQL Solutions for the Enterprise
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2020-02-12 06:52:42 | Re: WIP: WAL prefetch (another approach) |
Previous Message | Michael Paquier | 2020-02-12 05:42:01 | Re: Getting rid of some more lseek() calls |