Знающие люди, подскажите пожалуйста.

Была проблема с тем, что исчерпалось диское пространство.
Слил всю папку с данными в бекап.
Увеличил дисковое пространство, залил всё обратно.
Запустил. Сервер работает, после этого наблюдается странное поведение.

pg_wal распухает без остановки, при том, что данных фактически смешное колличество.
wal сегментов уже более тысячи. pg_wal занимает уже 16Gb. Выросло за час, хотя никаких данных фактически не заливалось.
При том, что стоят ограничения.

     max_wal_size: 2GB
     wal_keep_segments: "150"

Есть один физический слот репликации.

При попытке восстановить реплику с нуля, получаю ошибу
XX000,"invalid segment number 0 in file ""pg_internal.init.17034"""

Привет всем. Помогите пожалуйста понять как оптимизировать запрос.
Есть 2 таблицы к которым нужно применить JOIN, в одной таблице около 65 млн. строк (`csco_idesind`), в другой 336 млн. строк (`csco_ifndq`).
На входе был такой запрос:

SELECT k.gvkey, k.datadate, i.valuei, i.item, i.effdate, i.thrudate, k.datafmt
 FROM csco_idesind AS k
 INNER JOIN csco_ifndq i  ON k.coifnd_id = i.coifnd_id
WHERE k.gvkey IN (...gvkeys ~1600)
AND k.datadate BETWEEN '2013-10-01 00:00:00' AND '2015-04-01 00:00:00'

выхлоп анализатора:
Merge Join  (cost=11777177.79..119779025883.98 rows=7904066233200 width=42) (actual time=5929148.383..22674304.150 rows=39931455 loops=1)
  Merge Cond: (i.coifnd_id = k.coifnd_id)
  ->  Index Scan using csco_ifndq_coifnd_id_idx on csco_ifndq i  (cost=0.57..1205401664.09 rows=336723168 width=30) (actual time=2.838..22524320.405 rows=325599420 loops=1)
  ->  Materialize  (cost=11777177.22..11800650.71 rows=4694697 width=20) (actual time=108488.998..111424.490 rows=39931551 loops=1)
        ->  Sort  (cost=11777177.22..11788913.96 rows=4694697 width=20) (actual time=108488.981..108646.332 rows=179749 loops=1)
              Sort Key: k.coifnd_id
              Sort Method: external merge  Disk: 6024kB
              ->  Gather  (cost=1000.56..11064387.75 rows=4694697 width=20) (actual time=3.677..108369.271 rows=179749 loops=1)
                    Workers Planned: 2
                    Workers Launched: 2
                    ->  Parallel Index Scan using csco_idesind_datadate_idx on csco_idesind k  (cost=0.56..10593918.05 rows=1956124 width=20) (actual time=122.282..108262.504 rows=59916 loops=3)
                          Index Cond: ((datadate >= '2013-10-01 00:00:00'::timestamp without time zone) AND (datadate <= '2015-04-01 00:00:00'::timestamp without time zone))
                          Filter: (gvkey = ANY ('{~1600 items}'::integer[]))
                          Rows Removed by Filter: 1536564
Planning Time: 3.558 ms
JIT:
  Functions: 25
  Options: Inlining true, Optimization true, Expressions true, Deforming true
  Timing: Generation 26.070 ms, Inlining 210.727 ms, Optimization 269.278 ms, Emission 182.134 ms, Total 688.210 ms
Execution Time: 22676429.641 ms

после большого обновления данных как обновить индексы?

max_wal_size -- не ограничение. А способ задать частоту чекпоинтов. Из-за full page writes при частых чекпоинтах возникает много избыточной записи, сделайте их частоту меньше, и вала будет меньше (max_wal_size -- например, 16GB или 32; checkpoint_timeout -- например, 15 мин; надо понимать trade off: recovery time после сбоя будет больше)
Так можно компрессию включить -- wal_compression

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

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

ALTER TABLE user ADD COLUMN number INTEGER DEFAULT 0;

 Через psql и он ничего не отвечает через 2-3 минуты жму ctrl+c он пишет Ошибка, отмена реквеста пользователем.. подскажите что делаю не верно?

Версия пг какая?

psql (11.5 (Raspbian 11.5-1+deb10u1), сервер 10.13 (Ubuntu 10.13-1.pgdg16.04+1)

а можно для тех кто в танке?