From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Review: Display number of changed rows since last analyze |
Date: | 2013-07-01 12:51:11 |
Message-ID: | CABUevExfvVq1t8w7M-ZaPxCB8kPdYTxqSU-92+FsoCbF8iybzQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jul 1, 2013 at 2:48 PM, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> wrote:
> Magnus Hagander wrote:
>> On Mon, Jun 17, 2013 at 1:49 PM, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> wrote:
>>> This is a review of the patch in 5192D7D2(dot)8020605(at)catalyst(dot)net(dot)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/
From | Date | Subject | |
---|---|---|---|
Next Message | Albe Laurenz | 2013-07-01 13:15:44 | Re: Review: Display number of changed rows since last analyze |
Previous Message | Albe Laurenz | 2013-07-01 12:48:03 | Re: Review: Display number of changed rows since last analyze |