Magnus Hagander wrote:
> On Mon, Jun 17, 2013 at 1:49 PM, Albe Laurenz <laurenz.albe@wien.gv.at> wrote:
>> This is a review of the patch in 5192D7D2.8020605@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.
Yours,
Laurenz Albe