Re: n_ins_since_vacuum stats for aborted transactions

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Sami Imseih <samimseih(at)gmail(dot)com>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Euler Taveira <euler(at)eulerto(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: n_ins_since_vacuum stats for aborted transactions
Date: 2025-04-11 01:37:40
Message-ID: CAKFQuwZ4UmyYUdGM1ourY09Msd8+sP-2JQY=qEFMuvwCQ2KWjA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 10, 2025 at 5:38 PM Sami Imseih <samimseih(at)gmail(dot)com> wrote:

> > On Fri, 11 Apr 2025 at 02:01, Sami Imseih <samimseih(at)gmail(dot)com> wrote:
> > > I created an entry for the July CF
> > > https://commitfest.postgresql.org/patch/5691/
> > >
> > > ... and I realized I forgot to include David's code comment patch
> yesterday,
> > > Reattaching both patches.
> >
> > I've pushed the code comment patch.
> >
> > For the docs patch, the fact you're having to name specific fields in
> > the note at the bottom makes me think the details should be added to
> > the row for the field in question instead.
>
> Here is how per line will look like. Either way is fine with me.
> with v2, I also did add the clarification in the
> pg_stat_database.tup_inserted|
> updated|deleted fields as well.
>
>
I'm learning toward a hybrid. At the top:

"The tuple counters below, except where noted, are incremented even if the
transaction aborts."

(We can leave it unwritten that if the description says live or dead tuples
that qualifies as otherwise noted.)

The only exception I see that we need to note is: n_mod_since_analyze;
which I would explain as opposed to simply noting the oddity.

"Estimated number of rows modified since this table was last analyzed.
Aborted transactions are ignored here since they will not cause the
statistics computed by analyze to change."

So, here are the relevant counters, with their treatment of aborted
transaction tuples:

seq_tup_read - says live
idx_tup_fetch - says live
n_tup_ins - default notice
n_tup_upd - default notice
n_tup_del - default notice
n_tup_hot_upd - default notice (is this correct?)
n_tup_newpage_upd - default notice (is this correct?)
n_live_tup - says live (is this a counter?)
n_dead_tup - says dead (is this a counter?)
n_mod_since_analyze - inline reason for non-default
n_ins_since_vacuum - default notice

I'm also thinking to reword n_tup_upd, something like:

Total number of rows updated. Subsets of these updates are also tracked in
n_tup_hot_upd and n_tup_newpage_upd to facilitate performance monitoring.

David J.

P.S. I'm trying to understand what it means for rows from aborted deletes
to be counted (or not...).

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Guo 2025-04-11 01:41:14 Re: Add connection active, idle time to pg_stat_activity
Previous Message Michael Paquier 2025-04-11 01:10:46 Re: sync_standbys_defined read/write race on startup