>> 1. Why need to have 2 parameters (base threshold and scale factor) to
define
>> the threshold value, when either one of the parameter is more than enough
to
>> define the threshold value. Can you explain the significance of having
both
>> parameters. What is the real-time advantage of this?
>real-time advantage? They are just the two factors in a linear
>equation.
>> 2. Documentation says ".... If the number of obsolete tuples since the
last
>> VACUUM exceeds the "vacuum threshold", the table is vacuumed ...".
>> I also know about this table "pg_stat_user_tables" which has columns
>> n_tup_ins, n_tup_upd, n_tup_del, last_autovaccum and last_autoanalyze.
>> Since INSERT, UPDATE and DELETE count gets incremented everytime and do
not
>> reset after running autovacuum/autoanalyze, how does autovacuum
identifies
>> obsolete tuples since last VACUUM from this entries.
>There are two separate counters for live and dead tuples, IIRC (though
>they may not be exposed in the pg_stat views)
I've a stop/start of PostgreSQL service on a daily basis. Since these 2
counters are not stored/saved in tables and not available in pg_stat views
also, will these values be persisted/retained even after stop/start/restart?
>There are two separate counters for live and dead tuples
As per documentation, live tuples can always be obtained from
pg_class.reltuples. So, the question/answer here again would be to have
only counter on dead tuples since last VACUUM. Is my understanding right?
Is there some other/alternative way where I can check obsolete tuples at any
time since last VACUUM?
>> 3. Is there a way to see autovacuum daemon log entries?
>Not in 8.2.
From which next version of PostgreSQL is it available? Any pointers to
relevant documentation are appreciated.
>--
>Alvaro Herrera http://www.CommandPrompt.com/
>PostgreSQL Replication, Consulting, Custom Development, 24x7 support