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 facilitate performance 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)
v3-0001-Clarify-when-aborted-rows-are-tracked-for-tuple-r.patch
Description: Binary data
