Re: n_ins_since_vacuum stats for aborted transactions

I spent some time thinking about this today.

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

I like this idea, and I think it fits good as a blurb under "27.2.2.
Viewing Statistics"

I suggest a slight re-write however.

+  <para>
+   An aborted transaction will also increment tuple-related counters,
unless otherwise noted.
+  </para>

> 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_mod_since_analyze - inline reason for non-default
> n_ins_since_vacuum - default notice

All the counters mentioned above will increment the number of rows
modified/accessed even in the case of an aborted transaction, except
for n_mod_since_analyze.

> n_live_tup - says live (is this a counter?)
> n_dead_tup - says dead (is this a counter?)

They are not values that are purely incremental. They are incremented
by insert/update/delete for committed transactions, but are also
updated
by VACUUM or VACUUM FULL. So, these will need some inlined description
of their behavior,

> 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
facilitateperformance monitoring.
 

I think the current explanation is clear enough, I am also not too
thrilled about the "...to facilitate performance monitoring." since
the cumulative stats system
as a whole is known to be used to facilitate perf monitoring.

What do you think of the attached?

--
Sami Imseih
Amazon Web Services (AWS)



--
Sami Imseih
Amazon Web Services (AWS)