On Thu, Apr 17, 2025 at 11:13 PM David Rowley <dgrowle...@gmail.com> wrote:
>
> On Sat, 12 Apr 2025 at 07:33, Sami Imseih <samims...@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)
