Excerpts from Gordon Shannon's message of mié may 19 23:32:07 -0400 2010:
>
> alvherre wrote:
> >
> > n_live_tup and n_dead_tup corresponds to the current numbers,
> > whereas "last analysis tuples" are the values from back when the
> > previous analyze ran. These counters keep moving per update
alvherre wrote:
>
> n_live_tup and n_dead_tup corresponds to the current numbers,
> whereas "last analysis tuples" are the values from back when the
> previous analyze ran. These counters keep moving per updates, deletes,
> inserts, they are not static.
>
>
OK. Do you know how can I get th
Excerpts from Gordon Shannon's message of mié may 19 18:02:51 -0400 2010:
> I'm sorry, I'm not following you. Are you saying that "last analysis
> tuples" is "number of dead + live tuples from the previous anlyze"? If so,
> that would really confuse me because X would always be 0:
>
> X = lt +
alvherre wrote:
>
> Excerpts from Gordon Shannon's message of mié may 19 11:49:45 -0400 2010:
>
>> at: last analysis tuples = pg_class.reltuples
>>
>> I'm the least confident about the last one -- tuples as of last analyze.
>> Can anyone confirm or correct these?
>
> In 8.4 it's number
Excerpts from Gordon Shannon's message of mié may 19 11:49:45 -0400 2010:
> at: last analysis tuples = pg_class.reltuples
>
> I'm the least confident about the last one -- tuples as of last analyze.
> Can anyone confirm or correct these?
In 8.4 it's number of dead + lives tuples that there
In an effort to fine-tune my table storage parameters so tables are analyzed
at the optimal time, I have written a query to show how soon my tables will
be auto-analyzed. But my results to not jive with what I see autovacuum
doing, i.e. there are tables that are millions of rows past the threshold
