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

есть пример как запускается?а то я не нашел

в любом случае под такие объемы данных почти наверняка придется заниматься и какой-то доработкой приложения

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

запустится ли оно вообще, когда к постгресу подключения как такового нет, тольшо ошибка db is starting up

Очень даже не факт. Было бы адекватное "железо", казалось бы.

прочтите документацию, там все описано, в т.ч. и ваш кейс. Это очень элегантная утилита, с PG фактически не взаимодействует. Она только узнает какие файлы валов PG должен прочитать с диска во время старта и читает их в несколько потоков раньше его. В результате когда до этих файлов (валов) доходит очередь у PG (который читает последовательно в один поток) нужные файлы уже оказываются в Кеше ФС ОС, что существенно ускоряет ( у вас же не виндовс)

а что, у нас сейчас чтение в несколько потоков как-то сильно ускоряет disk-io ?

понятно, что preread в пределах кэша ускоряет, но при чем тут много потоков?

надо полагать, что этот единственный процесс занимающийся рестором -- не только одним чтением файлов занимается

Есть опыт с 2-3 млн записей ежедневно (на старте были сотни тысяч - постепенно растет объем). Без партиционирования. На данный момент 1,2 млрд записей (и это не логи)

Естественно аналитику по такой таблице не соберешь в лоб - применяется аналитика на триггерах (сейчас бы сделали через очередь и запись в аналитическое хранилище).


Вообщем очень зависит от характера нагрузки и от того, как вы будете данные извлекать (достать с 10-100 записей на такой таблице - не проблема - если выборка ложится на индексы).

Важно , чтобы механизм обработки самим приложением был асинхронным - вставка на таких объемах замедляется - ввиду наличия индексов и растет со временем

Объем БД 3+ ТБ, и это почти все "одна большая таблица" и немного справочников вокруг

Он делает вот это: "reads the stream of WAL records using pg_xlogdump and schedules concurrent IOs in order to prefault PostgreSQL heap pages into the follower’s filesystem cache.", а не prefetch самих WAL, поэтому помогает.

Здравствуйте. Что может означать данная ошибка, в какую сторону копать?
ERROR:  invalid memory alloc request size 12776525720924364720

В сторону контекста. ;)
Что она конкретно означает, написано в её тексте, а толку-то?
Т.е. выясните где/когда она происходит, воспроизведите / получите более подробное сообщение об ошибке.

да точно, страницы которые потребуютя

Yaroslav т.е. однозначно искать проблемы, связанные с памятью, а не диском и тд?  Контекст: разворачивал базу, восстанавливал из дампа. Также было развернуто приложение. Связка успешно функционирует без подобных ошибок на другой машине.

Нет, не однозначно. Т.е. без контекста это сообщение практически бесполезно.

> Контекст: разворачивал базу, восстанавливал из дампа.

Так найдите конкретное место (выполнявшийся SQL), где это происходит. Это обычно есть и в выводе pg_restore (psql), и в логах PostgreSQL.

Вопро пример запроса с ошибкой
[2020-08-09 13:49:45.156 MSK] ERROR:  invalid memory alloc request size 12776525720924364720
[2020-08-09 13:49:45.156 MSK] STATEMENT:  INSERT INTO error_log (source, message, status) VALUES ($1, $2, $3)

но не факт, что это конкретно этот запрос виноват. любой запрос после сбоя даст
ERROR:  invalid memory alloc request size 12776525720924364720