>>>>> "BH" == Brian Hirt <bhirt@mobygames.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@kciLink.com Rockville, MD +1-301-869-4449 x806
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
