Re: BUG #5946: Long exclusive lock taken by vacuum (not full)
От | Maxim Boguk |
---|---|
Тема | Re: BUG #5946: Long exclusive lock taken by vacuum (not full) |
Дата | |
Msg-id | AANLkTi=RtuZSVLUwWWfrEbYkA19thJ82Ub67ODTRPkux@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #5946: Long exclusive lock taken by vacuum (not full) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
On Sat, Mar 26, 2011 at 4:17 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Maxim Boguk" <Maxim.Boguk@gmail.com> writes: > > In my case vacuum tried to truncate last 10-15GB from 100Gb relation, and > > each time (3) it was cost 10+ minutes of service downtime (because that > > table was completely locked). > > > Is that correct behaviour? Are here any way to speedup that process or > at > > least allow read-only queries during that time? > > Use autovacuum --- if there's something that wants to access the table, > autovac will get kicked off the lock. (Of course, the table may never > get truncated then, but maybe you don't care.) > > regards, tom lane > Thank you for an idea. Are having lots empty pages at end of the table can have any negative impact on database performance (assuming I have plenty of free disk space)? In my case these 100Gb table going to be reduced to 20Gb size actual data located at start of the table, so I worry about possible negative impact of having extra 80Gb free space at end of the table. Regards, Maxim
В списке pgsql-bugs по дате отправления: