Re: pg_autovacuum seems to be a neat freak and cleans way too much

>>>>> "BH" == Brian Hirt <bhirt(at)mobygames(dot)com> writes:

BH> reltuples in pg_class is defined as a real, reltuples in
BH> pg_autovacuum is defined as an int. the query used to get reltuples
BH> returns scientific notation for my larg tables, '4.06927e+06' for the
BH> one i mention below. pg_autovacuum happily converts that to a '4'
BH> by doing atoi('4.06927e+06'), which is why it's all fubar for my
BH> large tables with over a million tuples.

Wow. What a difference the CVS pg_autovacuum makes in this case. I
was wondering why my large tables were vacuumed *every* iteration
thru, even though I set the churn rate to 3.0. It thought that my 150
million+ row table had 1 row in it! With the latest pg_autovacuum it
gets the numbers right. This one was worse than when we had the
overflow in the time computation causing it to sleep forever between
iterations... :-)

For anyone with large tables using pg_autovaccum, you *have* to update
to the latest version.

Thanks for starting this thread. I really is making a big difference
in my performance no having to run vacuum all the time. I was
beginning to think my table churn was much worse than it really is...

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: khera(at)kciLink(dot)com Rockville, MD +1-301-869-4449 x806
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/