но данные еще в wal будут продублированны. только в оперативной памяти можно гарантировано занулить данные наверно

Добрый день. Используете ли в проектах Percona Toolkit? Произошла дискуссия с коллегами по обновлению больших таблиц. В MySQL это делается посредством данных инструментов в том числе. Хотелось бы узнать, кто как решает аналогичные задачи в PostgreSQL.

уточните: какие конкретно задачи?

Например, добавить новое поле в таблицу с N млн. записей.

Сейчас читаю вот эту документацию, здесь описано решение: https://github.com/reorg/pg_repack/blob/master/doc/pg_repack.rst#full-table-repacks

вы усложняете.
читайте официальную доку прежде всего, добавить новое поле в таблицу просто:
ALTER TABLE tab ADD col integer;

Если вы добавите DEFAULT значение или NOT NULL — это будет долго, таблица будет целиком переписана.
Начиная с 12-й версии (если не ошибаюсь), можно делать DEFAULT, это не приведёт к переписыванию таблицы. NOT NULL — приведёт.

pg_repack — это вообще про другое, он не добавляет колонки.

Я понимаю, что это про создание новой таблицы и её последующее использование вместо текущей.

Я просто хотел послушать, принято так делать или всё решается штатными средствами. Или ещё как-то

Спасибо, что просветили про default / not null. Натыкался даже на статью об этом.

pg_repack это крайнее средство. Обычно достаточно аккуратно настроенного вакуума.

мы им таблицы и/или индексы между табличными областями таскаем онлайн, полезно

А я и сам широко пользовался при массовых изменениях больших таблиц - быстро, надёжно и "на лету". Знать и уметь пользоваться конечно надо, но смысла при обычной работе в нём нет.

А просто VACUUM что физически делает?

java-прилага выдает
13:52:28.685 WARN [ActiveMQ Broker[amq-broker] Scheduler] Failed to browse Topic: ReturnCurrencyExchangeRateTopic
java.io.IOException: Failed to recover container. Reason: org.postgresql.util.PSQLException: Ran out of memory retrieving query results.

в логах сервера ничего.
есть еще pg-pool - там тоже ничего

собственно один вопрос: это проблема JDBC драйвера?

это явно не проблема Postgres-а, зачем это тут?

Hi everyone, I just want set constraint mode as  DEFERRED for CHECK constraint, is it possible? it should validate end of transaction

извечная борьба админов и прогеров (((
вот хотел убедиться

Доброго дня ещё раз.
К сожалению, разбор полётов с базой пришлось отложить ввиду новых более приоритетных задач. Поскольку сейчас они в нужной степени решены, разбор полётов возвращается.
С моего последнего апдейта изменилось следующее:
1. Проблема с ООМ осталась (ниже более подробно)
2. Проблема с быстрым заполнением Storage пропала. Просто поднял новую базу с той же конфигурацией, теми же воркерами и проблема исчезла. Почему, из-за чего — без понятия. Но раз пока пропала, то меньше головная боль.

Проблема с RAM. Как вы можете видеть, в прикреплённом мной предыдущем сообщении имеется график использования RAM за 6 часов. Непонятно из-за чего он поменял вид, но проблема осталась. Прислушавшись к вашим советам по поводу смены облачного решения на собственный сервер с PostgreSQL, было решено поднять его с помощью пакета Bitnami. Основной момент, почему был вообще выбран клауд — это быстрое развертывание, сразу установленные мониторинги, возможность менять какие-то конфигурации прямо на лету.

Другой момент, который хотелось бы озвучить.
Как упоминали ранее, лучше иметь в команде DBA, который будет в этом разбираться. Но на данный момент это не представляется возможным. С Postgres мы работаем в первый раз, и тонкостей, естественно не знаем, и переходить на другую базу, скорее всего, не будем в виду того, что придётся так или иначе переписывать воркеры и другие сервисы, и дополнительно это не отменяет того факта, что в другой базе не будет аналогичных проблем.

Возвращаясь к сути вопроса: увеличение RAM и количество соединений. В данный момент необходимо запроцессить исторические данные. Записей около 100 млн. Конечно же это нужно сделать в кратчайшие сроки, чтобы можно было выполнять дальнейшую работу по анализу полученных данных и сделать и итоге MVP, которое покажет суть работы.
У нас имеются воркеры, которые могут обрабатывать в сумме до 5,000 записей (и больше, в зависимости от поднятых машин) в секунду. Операции которые выполняют воркеры — самые простые, без кучи связей (4 таблицы всего, в сумме 21 колонок):
1. Проверка записи на существование в базе
2. Добавление записи в базу
Такие процессы выполняются без батчей. Какой pool_size указан в воркере, столько операций insert/exists выполняется одновременно.
Отсюда и вытекает необходимость в большом количество подключений к базе. На данный момент переписывать логику работы воркеров трудозатратно и, по сути, бессмысленно, т.к. нужно проделать эту операцию (прогон исторических данных) всего один раз. С дальнейшими ежедневными обновлениями справится и 1-2 воркера на каждый сервис, которые, естественно, базу в текущем положении не положат.
И опять возвращаясь к вопросу: возможно ли в данный момент настроить Postgres так, чтобы он не падал от 3-4 тысяч активных подключений к нему? Конфигурация база может быть любой: CPU, RAM, Storage.
Из возможных вариантов пробовал PGTune. Но поскольку я это пробовал всё ещё на Google Cloud SQL, то некоторые параметры настроить было невозможно. Возвращаясь к использованию Bitnami (будет собственный сервер с возможностью настройки postgres.conf) — поможет ли PGTune в данном случае? Указание RAM, CPU, количества подключений — и подтверждение изменения предложенных им [PGTune] конфигов. Либо нужно что-то другое?

P.S. Прикрепляю график RAM за весь день. Можете сравнить его с тем, что было в предыдущий раз. Стало хуже, хоть и изменилась только база. В моменты, когда графики идут на спад — база недоступна — воркеры висят. В прошлый раз спад был практически моментальный, из-за чего воркеры начинали работать в течение нескольких минут.