Re: pg_autovacuum seems to be a neat freak and cleans way too much - Mailing list pgsql-general

From Vivek Khera
Subject Re: pg_autovacuum seems to be a neat freak and cleans way too much
Date
Msg-id x7isepmrnw.fsf@yertle.int.kciLink.com
Whole thread Raw
In response to pg_autovacuum seems to be a neat freak and cleans way too much  (Brian Hirt <bhirt@mobygames.com>)
List pgsql-general
>>>>> "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/

pgsql-general by date:

Previous
From: Robert Treat
Date:
Subject: Re: [ADMIN] Clustering Postgres
Next
From: jseymour@LinxNet.com (Jim Seymour)
Date:
Subject: Re: Does INSERT inserts always at the end ?