Re: Effects of dropping a large table

Поиск
Список
Период
Сортировка
От Rob Sargent
Тема Re: Effects of dropping a large table
Дата
Msg-id c9fea9c6-807c-474f-d698-968d3ac2a901@gmail.com
обсуждение исходный текст
Ответ на Re: Effects of dropping a large table  (David Rowley <dgrowleyml@gmail.com>)
Список pgsql-general
On 7/19/23 17:15, David Rowley wrote:
On Wed, 19 Jul 2023 at 07:41, Rob Sargent <robjsargent@gmail.com> wrote:
You might consider deleting portions of the table in separate (consecutive) batches (maybe 5% per delete).  And then truncate table is not logged so that might be an alternative.
Can you explain why this would be a useful thing to do?

It sounds to me like it would just create a load of needless WAL from
the deletes and the vacuum that cleans up the dead rows each of which
is more likely to cause lag problems on the replica servers, which the
OP is trying to avoid.

David
No, you're right.  I was remembering problems with _deleting_ essentially all of a large table (with limited resources).  The drop might not have the same problem.  But aren't they logged/transactional and then in the WALs anyway.

В списке pgsql-general по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Effects of dropping a large table
Следующее
От: Amn Ojee Uw
Дата:
Сообщение: Nu-B here