Уважаемые, как лучше "обрезать" табличку, оставив за последние 2 месяца?

Есть таблица (лог) за 5 лет. 250гиг. Индекс по Id и статусу. Дата есть но без индекса.

Особо не выпендриваясь -- DELETE FROM WHERE date<... За несколько часов закончит. Всё это время простые INSERT смогут идти, большынство SELECT -- нет.

По опыту из оракла — удалять в цикле небольшими порциями (тысяч по 10 — 50), с промежуточными коммитами.

Ну или как вариант - переложить рядом 2 месяца, а остальное дропнуть. Быстрее может отработать. create а потом insert rename rename в одной транзакции.

на проде неприемлемо.

так же. индекса нет по дате. а селект просто убьет базу. Сколько будет строиться индекс?

Природа id* известна? Если это лог, то он строго возрастающий, это верно? Достаточно примерно определить границу для селекта. А в новой таблице уже подумать про партицирование и более удачную структуру хранения.

В 98% случаев прода -- вполне приемлемо. В остальных -- ну, рубите по частям. Хоть DELETE FROM WHERE date < (нужная - 3 года) и т.д., хоть DELETE FROM WHERE date < нужная AND id<какое-то небольшое значение, куда немного попадёт. Первое будет по-минимум отрабатывать минут 5-10, встревать на это время будут только селекты, которые могут получить значения из данных дат. Второе можно сделать практически мгновенным, но суммарно время выполнения будет большэ. Но, ещё раз -- я не очень верю, что у вас как-то сложно запланировать тех.промежуток в котором ваша аналитика не будет читаться.

Можно найти нужный id (если там int), начиная с которого идут даты за последние 2 месяца. И удалить все записи, что меньше него.

Здесь не оракл, тут свои погремушки. Там да, там сто миллионов сразу удалённых -- это повод для лулзов и лучшэ так не нарываться.

ID похоже простой инкремент. Буду просто бить диапазон и удалять маленькими кусочками в цикле :) Спасибо всем за идеи.

Я так и делал однажды

Если в критэриях удаления добавить и дату -- то и удалится ровно столько жэ. Но если всей пачкой удалять -- то никакой выгоды, только замедление.

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

Баз с реально большым объёмом обновлений, которым замершый на несколько часов автовакуум будет создавать проблемы -- не так много.

Все как обычно ) так сложилось исторически. данные вообще не нужны в безе =( просто кому то там удобнее искать.

Да, вакуум после такого может долго идти.(

Типа брать кусками по возрастанию id, пока не наткнёмся на нужную дату?

Типа брать кусками по возрастанию id, всегда добавляя к условию правильную дату. Тогда не удалится ничего лишнего. Останавливаться ли при этом на каких-то id в районе той даты (можно с запасом +пара дней) или нет -- ужэ не так важно.

А, ещё, если у вас по умолчанию транзакцыи serializable (обычно это не так) -- то смените для этого удаления на repeatable read или read committed.

Я подвешиваю новый "партишн" через инхеритенс и констрайнт .Свап имена. В результате все пишется в новую таблицу , а читается с обеих. Через два месяца - дроп старую