Re: pg_autovacuum seems to be a neat freak and cleans way too much
От | Vivek Khera |
---|---|
Тема | Re: pg_autovacuum seems to be a neat freak and cleans way too much |
Дата | |
Msg-id | x7isepmrnw.fsf@yertle.int.kciLink.com обсуждение исходный текст |
Ответ на | pg_autovacuum seems to be a neat freak and cleans way too much (Brian Hirt <bhirt@mobygames.com>) |
Список | 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 по дате отправления: