Ну и как я понял, если у обновляемое поле данных

есть в индексе, то hot update не светит вообще ?

Вроде да.

и решить вопрос с раздуванием базы можно только vacuum full ? просто оно тоже добавит как iops, так и износ ssd диска, ну и блокировки таблицы...

Почему full? Обычный тожэ вроде неплох.

От блокировок есть pg_repack...

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

Сделайте хранимку, делов-то.

как мне из хранимки запустить (execv) /usr/local/bin/pg_repack ? тем более, что оно еще и пароль просит с stdin (поправимо, конечно).

ну и вопрос, а как этот pg_repack будет работать, когда есть репликация ? я так и не понял, он сам в файлы лазит или через сам сервер только команды дает ? тогда почему он экзешник, а не хранимка сам ? https://github.com/reorg/pg_repack/issues/196 - пишут, что оно хранимкой быть не может.

Либо через copy to |, либо через любой unsafe pl. Пароль скорее всего не будет просить, поскольку на юзера postgres обычно стоит аутэнтификацыя peer. Команды даёт через сервер.

при репликации оно требует каких-либо действий на том сервере, куда льются данные ? ну кроме как загрузка модуля расширения ?

Нет.

а вы это делали или это только теория ? так как если запускать подобным образом через copy, то оно ждет пока завершится сама транзакция с COPY . & - не помогает - там sh , который запускает postgres ждет зомби процесс. но, даже если написать на сях "форкалку", которая будет делать fork() и waitpid() то все равно COPY завершится раньше, чем pg_repack, что не очень то желательно, так как надо хотя бы знать, что оно отработало.

делал. через. COPY давал на вход sed-скрипту данные о новом пользователе, который менял/добавлял баунсеровский userlist.txt. вы вывод COPY даёте на вход подпроцессу, естественно, что мы будем ждать окончания подпроцесса.

ну так pg_repack будет ждать пока завершится COPY, который ждет пока завершится pg_repack.

Весело. Я бы запускал через COPY TO PROGRAM nohup & , выводил вывод в файл, потом читал его через COPY FROM если хочется результата. Но так, конечно, дажэ проще. ЗЫ Хотя кому я вру? Не было бы у меня необходимости ЭТО делать через хранимку. Всё равно обвязка какая-то есть от интэрфейса пользователя до базы, вот обвязка бы и пинала pg_repack.

если nohup и & , то будет зомбак, так как bash/sh не делает waitpid(pid, WNOHANG) после fork() и будет висеть как зомби пока не завершится форк . А пока оно висит, pg_repack ждет завершения текущих транзакций, в том числе и COPY которая ждет пока отработает pg_repack. Как то так.

Я, кстати, непонимаю о чём вы и с чего это взяли. никакого зомби там быть не должно, поскольку родительский процэсс /bin/sh быстро завершается -- и сам этот pg_repack переприсоединяется к init. Который делает waitpid(). COPY (SELECT 1) TO PROGRAM 'sleep 50 &'; завершается мгновенно, в pg_locks ничего не остаётся.

а я хочу еще и дождаться окончания выполнения pg_repack, а так оно сразу отваливается.

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

ну это костыль. я хотел create temporary table repack (str text not null default ''); потом copy repack (str) from program '/usr/local/bin/pg_repack -d .... &'; но оно клинит: 280596 ? Ss 0:00 \_ postgres: 13/main: postgres xxx [local] COPY 282483 ? Z 0:00 | \_ [sh] <defunct>