From: | Sami Imseih <samimseih(at)gmail(dot)com> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | 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-09 22:53:56 |
Message-ID: | CAA5RZ0usiQ5X7cHU2b+8MsXmZxukBRPxiQqwNzA2kz2JkzFXwQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Except there isn’t some singular provably correct value here. Today’s behavior (considering dead tuples)
> is not intrinsically wrong nor correct, and neither is what you propose (ignoring the dead tuples).
> The fact that those dead tuples get removed regardless is a point in favor of counting them when deciding what to do.
> And it’s also the long-standing behavior. You need to make a compelling argument to change to your preference.
>
> Inserting aborted dead tuples moves the counter closer to both autovacuum thresholds.
> There is no reason why that should be prohibited. I can see the argument for why one
> threshold should be dead tuples only and the other live tuples only - but I don’t favor that design.
Fair enough, and I think I got my answers from this thread. This
design decision was not
discussed in the thread for b07642dbcd8.
So, I think public documentation updates to clarify that
n_tup_upd|del|ins, and n_ins_since_vacuum include
aborted rows is a good enhancement.
Also a code comment in pgstat_relation_flush_cb that explains
ins_since_vacuum intentionally includes aborted inserts.
tabentry->ins_since_vacuum += lstats->counts.tuples_inserted;
--
Sami Imseih
From | Date | Subject | |
---|---|---|---|
Next Message | Jacob Champion | 2025-04-09 23:08:33 | Re: [PoC] Federated Authn/z with OAUTHBEARER |
Previous Message | David G. Johnston | 2025-04-09 22:30:18 | Re: n_ins_since_vacuum stats for aborted transactions |