Magnus Hagander wrote: >>> On Mon, Jun 17, 2013 at 1:49 PM, Albe Laurenz <laurenz.a...@wien.gv.at> >>> wrote: >>>> I think that the column name is ok as it is, even if it >>>> is a bit long - I cannot come up with a more succinct >>>> idea. Perhaps "n_changed_since_analyze" could be shortened >>>> to "n_mod_since_analyze", but that's not much of an improvement. >>> >>> AFAICT it's related to "n_live_tup", and "n_dead_tup". How about just >>> "n_mod_tup"? Though that doesn't convey that it's since the last >>> analyze, I guess. >>> >>> But given that both n_dead_tup and n_live_tup don't really indicate >>> that they're not "since the beginning of stats" in the name (which >>> other stats counters are), I'm not sure that's a problem? It would be >>> a name that sounds more similar to the rest of the table. >> >> I don't get that. >> >> As far as I know, n_dead_tup and n_live_tup are estimates for >> the total number of live and dead tuples, period. >> >> Both numbers are not reset to zero when ANALYZE (or even VACUUM) >> takes place. > > No, but they are zero *until* vacuum runs. > > The point I was trying to make was that they are showing an absolute > number. Unlike for example n_tup_inserted and friends which show the > total number of <event> since stat reset.
Ok, I understand you now. All the old names are fairly intuitive in my opinion. "Number of life tuples since the statistics were reset" doesn't make a lot of sense to me, so I would automatically read that as an absolute number. But it would not be clear to me that "n_mod_tuples" are counted since the last ANALYZE (different from other columns); I would jump to the conclusion that it is a sum of n_tup_ins, n_tup_upd and n_tup_del. So I think that a name that it less likely to cause confusion would be better that a short, but misleading name. Yours, Laurenz Albe -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers