From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: RFC: Detailed reorder buffer stats dumps |
Date: | 2021-05-05 18:28:43 |
Message-ID: | 20210505182843.jdsl66la4beoqdqw@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2021-05-05 18:33:27 +0800, Craig Ringer wrote:
> I'm thinking of piggy-backing on the approach used in the "Get memory
> contexts of an arbitrary backend process" patch in order to provide access
> to detailed reorder buffer content statistics from walsenders on request.
>
> Right now the reorder buffer is mostly a black-box. I mostly rely on gdb or
> on dynamic probes (perf, systemtap) to see what it's doing. I intend a
> patch soon to add a couple of fields to struct WalSnd to report some very
> coarse reorder buffer stats - at least oldest buffered xid, number of
> buffered txns, total bytes of buffered txns in memory, total bytes of
> buffered txns spilled to disk.
>
> But sometimes what I really want is details on the txns that're in the
> reorder buffer, and that's not feasible to export via always-enabled
> reporting like struct WalSnd. So I'm thinking that the same approach used
> for the memory context stats patch might work well for asking the walsender
> for a detailed dump of reorder buffer contents. Something like a
> per-buffered-txn table of txn topxid, start-lsn, most recent change lsn,
> number of changes, number of subxids, number of invalidations, number of
> catalog changes, buffer size in memory, buffer size spilled to disk.
>
> Anyone drastically opposed to the idea?
I am doubtful. The likelihood of ending with effectively unused code
seems very substantial here.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Joel Jacobson | 2021-05-05 18:35:03 | Re: COPY table_name (single_column) FROM 'unknown.txt' DELIMITER E'\n' |
Previous Message | Andres Freund | 2021-05-05 18:25:46 | Re: MaxOffsetNumber for Table AMs |