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)
