On Mon, Jul 1, 2013 at 2:48 PM, Albe Laurenz <laurenz.a...@wien.gv.at> wrote: > Magnus Hagander wrote: >> On Mon, Jun 17, 2013 at 1:49 PM, Albe Laurenz <laurenz.a...@wien.gv.at> >> wrote: >>> This is a review of the patch in 5192d7d2.8020...@catalyst.net.nz >>> >>> The patch applies cleanly (with the exception of catversion.h of course), >>> compiles without warnings and passes the regression tests. >>> >>> It contains enough documentation, though I'd prefer >>> "Estimated number of rows modified since the table was last analyzed" >>> to >>> "Estimated number of row changes (inserts + updates + deletes) since the >>> last analyze" >>> >>> The patch works as it should, and I think that this is a >>> useful addition. It only exposes a value that is already >>> available internally, so there shouldn't be any penalties. >>> >>> 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. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers