Re: n_ins_since_vacuum stats for aborted transactions - Mailing list pgsql-hackers

On Thu, Apr 17, 2025 at 11:13 PM David Rowley <dgrowleyml@gmail.com> wrote:
>
> On Sat, 12 Apr 2025 at 07:33, Sami Imseih <samimseih@gmail.com> wrote:
> > What do you think of the attached?
>
> I looked at the v3 patch and I'm having trouble getting excited about it.
>
> I'd say this part is misleading:
>
> @@ -3956,7 +3961,8 @@ description | Waiting for a newly initialized
> WAL file to reach durable storage
>         <structfield>n_dead_tup</structfield> <type>bigint</type>
>        </para>
>        <para>
> -       Estimated number of dead rows
> +       Estimated number of dead rows (updated by committed transactions, or by
> +       <command>VACUUM</command> and <command>VACUUM FULL</command>)
>        </para></entry>
>
> An aborted insert will contribute to that counter, but that's not mentioned.

I thought the first line "An aborted transaction will also increment
tuple-related counters, unless otherwise noted."
makes it clear that it will be updated in an aborted transaction, but
after re-reading
I can see it being confusing. What about this wording to make it more
clear when the field is
updated?


        <structfield>n_dead_tup</structfield> <type>bigint</type>
       </para>
       <para>
-       Estimated number of dead rows
+       Estimated number of dead rows (updated either by committed or
aborted transactions,
+       or by <command>VACUUM</command> and <command>VACUUM FULL</command>)
       </para></entry>
      </row>

> Would it be ok just to adjust n_mod_since_analyze's "Estimated number
> of rows modified since this table was last analyzed" and inject "by
> committed transactions" after "modified", then call it a day?

That works also.

--
Sami Imseih
Amazon Web Services (AWS)