@vyegorov не соглашусь. "At checkpoint time, all dirty data pages are flushed to disk and a special checkpoint record is written to the log file." Таким образом одномоментно база пытается записать checkpoint_segments * checkpoint_completion_target * 16MB данных на винчестер. в данном случае это около 15GB.
вы всегда постучавшись по этому порту можете организовать тоннель в обе стороны, в этом не проблема :) а по нему уже хоть что, хоть репликацию хоть торренты :)
у постгри нет мультимастера, мастер всегда кто-то один, а все остальные read-only. пишите нечто своё которое будет уметь скидывать свежие данные в общую базу.
ну если еще и интернет может отвалиться тогда про репликацию забудьте. пишите приложение которое накапливает и периодически сливает данные в базу которая не в поле. в поле вся база не нужна.
таблицу следовало создать с некоторым fillfactor отличным от 100, например 80 - 85. и индекс тоже, кстати. reindex и vacuum обычно не нужны при включенном autovacuum
1) чтобы взять строчки с 100 по 115 первые 100 базе всё равно надо выбрать, а в результатах отбросить, так что при offset'е вы выбираете offset+limit строк
2) размеры таблицы и индексов в мегабайтах укажите плз
4) оно просто организует записи в таблице в том порядке в котором они идут в индексе, при поиске по индексу будет меньше random read
5) уложите таблицу в shared_buffers, ибо винты не быстрые. размер shared_buffers обычно указывают как 1/3 либо 2/3 RAM. В зависимости от необходимости.
pg_last_xact_replay_timestamp - это "time stamp of last transaction replayed during recovery.", или же время последней накаченной транзакции, а если мастер не совершает никаких транзакций то и накатываться нечему, а разница во времени растёт и показывает большой лаг, хотя его на самом деле нет
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.