Re: problems with large table

Поиск
Список
Период
Сортировка
Искать
От
Mike Charnoky
Тема
Re: problems with large table
Дата
Msg-id
46E84606.3010501@nextbus.com
Ответ на
Список
Дерево обсуждения
problems with large table Mike Charnoky <noky@nextbus.com>
Re: problems with large table "Joshua D. Drake" <jd@commandprompt.com>
Re: problems with large table Alvaro Herrera <alvherre@commandprompt.com>
Re: problems with large table Tom Lane <tgl@sss.pgh.pa.us>
Re: problems with large table Mike Charnoky <noky@nextbus.com>
Re: problems with large table Alvaro Herrera <alvherre@commandprompt.com>
Re: problems with large table "Phoenix Kiula" <phoenix.kiula@gmail.com>
Re: problems with large table Alvaro Herrera <alvherre@commandprompt.com>
Re: problems with large table Tom Lane <tgl@sss.pgh.pa.us>
Re: problems with large table "Phoenix Kiula" <phoenix.kiula@gmail.com>
Re: problems with large table Mike Charnoky <noky@nextbus.com>
I have never heard that stopping a vacuum is problematic... I have had
to do this many times in the past without any adverse affects.  Is there
some sort of documentation which elaborates on this issue?

For the record, I did a VACUUM ANALYZE, not FULL.  Now that I think
about it, I probably should have used VERBOSE to see what is happening.
 Nothing else was accessing the database, so no process had a lock on
the table.

Tom, regarding insufficient patience: are you suggesting that it is
normal for a vacuum of a table this size to take more than two days
under these circumstances?  maintenance_work_mem is 16384.

Joshua: I'm copying the data to a new table right now, I'll see how that
goes.

Alvaro: The cluster suggestion probably won't help in my case since data
in the table should already be naturally ordered by date.


Mike

Tom Lane wrote:
> "Joshua D. Drake"  writes:
>> At this point, you are in a world of hurt :). If you stop a vacuum you
>> have created a huge mess of dead rows in that table.
> 
> Only if it was a vacuum full, which he didn't mention having tried.
> 
> I'm kinda wondering whether the vacuum and reindex did anything at all,
> or were blocked by some other process holding a lock on the table.
> If they weren't blocked, then the problem is insufficient patience,
> possibly combined with insufficient maintenance_work_mem.
> 
> 			regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
В списке pgsql-general по дате отправления
От: Uwe C. Schroeder
Дата:
От: Alvaro Herrera
Дата:
Сообщение: Re: problems with large table
FAQ