Я не говорил что будет быстрее.

И это будет тупо гораздо дольше, больше ничего.
Вот из какой СУБД у Вас такие привычки, где разработчики умудрились так накосить, что у них курсор работает быстрее простого DELETE FROM, а? ;)

Из легко заметного:
1. btree индексы стали занимать в 3 раза меньше места и ощутимо быстрее.
2. В 13  ORDER BY a, b может использовать индекс по a и досортировать по b, до этого нужен был индекс именно a, b.
3. В 10-м постгресе LIKE не умеет ускоряться за счёт триграммных индексов, а регулярки не используют SPGIST. В 13-м работают почти все комбинации (LIKE 'bla' ускорят в 14-м), хотя LIKE по триграммам всё равно в 2-3 раза медленнее регулярок ищет. Но это где-то в 11 и 12 ускорили.

Ну так тогда этим есть смысл заниматься только для защиты от отката в случае "падения" сервера.

таблица загружалась с помощью copy from 2 дня, попробую еще вариант почистить исходный csv и загрузить заново... может так быстрее будет...

хорошо) спасибо за помощь

таблица загружалась с помощью copy from 2 дня, попробую еще вариант почистить исходный csv и загрузить заново... может так быстрее будет...

Ты запустишь delete, он будет работать скажем неделю.
Если что не так - он встанет, а что он сделал - откатиться (это ещё неделя).

И потом снова неделю исправлять.... И так пока не случится идеальный delete

> Если что не так - он встанет,

Постоит и пойдёт дальше (когда транзакция, которая его блокировала, завершится), ничего страшного.

> а что он сделал - откатиться (это ещё неделя).

А эти опасения у Вас из какой СУБД? ;) ROLLBACK в PostgreSQL почти всегда происходит мгновенно, причём независимо от выполненного в транзакции объёма работы, just FYI.

> Если что не так - он встанет,

Постоит и пойдёт дальше (когда транзакция, которая его блокировала, завершится), ничего страшного.

> а что он сделал - откатиться (это ещё неделя).

А эти опасения у Вас из какой СУБД? ;) ROLLBACK в PostgreSQL почти всегда происходит мгновенно, причём независимо от выполненного в транзакции объёма работы, just FYI.

погодите, вы тут написали что все проверки успешны, но при этом снаружи к базе никто не может подключиться? это слегка противоречит пункту с ss.

покажите docker-compose ps грепнув вывод по имени контейнера с БД

Привет) не могу придумать как эффективно решить задачу:
есть таблица (5 млрд) с полями key varchar, value varchar,
В большинстве value лежит IP-адрес, но есть плохие данные, где там фигня вместо IP.
Вопрос: как можно эффективно убрать плохие данные, оставив value где только IP?
Пробовал выбирать с regexp (~) - очень долго
При insert в таблицу с value inet - ошибка
Может какой-то индекс нужно построить? или как-то иначе...

Триграммный индекс не пробовали?

Я имел в виду ошибку

Нормально написанный DELETE может прервать разве что deadlock (и т.п.), а если к этой таблице никто больше не обращается, это не проблема. Вот "падение" / перезапуск сервера PostgreSQL (по несвязанным причинам) в это время — это риск, да.

да, наверное самое правильное - чистить csv и потом уже cope from

День добрый.

Можно ли из jsonb по кейсу исключить несколько значений?

SELECT ('{"status_id": {"n": "001", "o": "002"}, "type": {"n": "other", "o": null}}' :: JSONB)
          - CASE WHEN TRUE THEN 'status_id' END

Например если в THEN попадает - исключить n полей, а в ELSE другие n полей