From: | Dragan Zubac <zubac(at)vlayko(dot)tv> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Paragon <lr(at)pcorp(dot)us>, pgsql-general(at)postgreSQL(dot)org |
Subject: | Re: VACUUM hanging on PostgreSQL 8.3.1 for larger tables |
Date: | 2008-04-13 23:22:57 |
Message-ID: | 480295D1.2090702@vlayko.tv |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hello
If Your 'vacuum verbose analyze table' ends pretty fast,and Your 'vacuum
full verbose analyze table' never ends,watch for 'select count (*) from
pg_locks',might be that You have some heavy load transaction processing
on that table,so 'vacuum full....' wait for transactions to end. If
possible kill all processes that access that table and try 'vacuum full
verbose analyze table'. Anyway,if processor is mostly idle,always check
'select count (*) from pg_locks' , at least in my experience.
Sincerely
Dragan Zubac
Tom Lane wrote:
> "Paragon" <lr(at)pcorp(dot)us> writes:
>
>> Right now I have
>> vacuum_cost_delay = 600
>>
>
> Yikes. That's *way* too high. If you're trying to get the vacuum to
> complete quickly, it really should be zero anyway. Nonzero is for when
> you don't care how long vacuum takes as long as it's not sucking too much
> I/O from your real work.
>
> regards, tom lane
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Stefan Schwarzer | 2008-04-14 05:47:21 | The default text search configuration will be set to "simple" ? |
Previous Message | Paragon | 2008-04-13 23:13:37 | Re: VACUUM hanging on PostgreSQL 8.3.1 for larger tables |