и ещё вопрос по поводу:

name_servers INTEGER[] NOT NULL,

я потом на него делаю GIN  индекс, но как раз хочется уйти от INTEGER ARRAY и придти к TEXT ARRAY, только вот есть затык - вчера пробовал сделать такое и у меня не работает оператор <@, ругается на: ERROR: operator does not exist: text[] <@ character varying[]

Может быть есть смысл использовать jsonb? Можно ли там делать поиск через похожие опреации (когда ищутся все значения в поле, например, {1,2} в поле {3,2,1} - заберет такую строку)?

ссылку я увидел сегодня, а тестил вчера 😄

с jsonb что-то такое прокатит?

и ещё вопрос по поводу:

name_servers INTEGER[] NOT NULL,

я потом на него делаю GIN  индекс, но как раз хочется уйти от INTEGER ARRAY и придти к TEXT ARRAY, только вот есть затык - вчера пробовал сделать такое и у меня не работает оператор <@, ругается на: ERROR: operator does not exist: text[] <@ character varying[]

Может быть есть смысл использовать jsonb? Можно ли там делать поиск через похожие опреации (когда ищутся все значения в поле, например, {1,2} в поле {3,2,1} - заберет такую строку)?

сделать поле TEXT[], а не VARCHAR[]?

Всем привет. Вопрос есть, помогите пожалуйста кто разбирается.

Если восстанавливаться с бэкапа, сделанного с помощью wal-g, но нету wal-логов, возможно ли запустить бэкап на момент снятия самого бэкапа, без дальнейшего восстановления из архивов?

И какие последствия этого могут быть?

и ещё вопрос по поводу:

name_servers INTEGER[] NOT NULL,

я потом на него делаю GIN  индекс, но как раз хочется уйти от INTEGER ARRAY и придти к TEXT ARRAY, только вот есть затык - вчера пробовал сделать такое и у меня не работает оператор <@, ругается на: ERROR: operator does not exist: text[] <@ character varying[]

Может быть есть смысл использовать jsonb? Можно ли там делать поиск через похожие опреации (когда ищутся все значения в поле, например, {1,2} в поле {3,2,1} - заберет такую строку)?

Может все же будет у вас время глянуть.
Партиции пока подкинуть не удалось. Уменьшил кол-во вхождений в запросе IN, меньше уже сатанисты не дают.
В итоге получаю около 6.5 минут на запрос. Но с таким хаком: создал временную таблицу:

create temp table csco_idesind_2008_2020 as
select gvkey, datadate, datafmt from csco_idesind where datadate BETWEEN '2008-01-01 00:00:00' AND '2020-07-01 00:00:00' order by datadate;

Запрос в итоге таков:

ex

plain analyze SELECT k.gvkey, k.datadate, i.valuei, i.item, i.effdate, i.thrudate, k.datafmt
    FROM csco_ifndq AS i
    JOIN csco_idesind_2008_2020 AS k ON k.coifnd_id = i.coifnd_id
    WHERE k.gvkey IN (...500)
               AND
               k.datadate BETWEEN '2013-10-01 00:00:00' AND '2015-09-01 00:00:00'

и выхлоп анализатора:

Merge Join  (cost=62421496.84..4363959802.57 rows=286713043089 width=80) (actual time=359989.974..388725.779 rows=16478093 loops=1)
  Merge Cond: (k.coifnd_id = i.coifnd_id)
  ->  Sort  (cost=372058.39..372484.13 rows=170296 width=58) (actual time=16753.887..16763.030 rows=68442 loops=1)
        Sort Key: k.coifnd_id
        Sort Method: quicksort  Memory: 8420kB
        ->  Bitmap Heap Scan on csco_idesind_2008_2020 k  (cost=4748.49..357261.64 rows=170296 width=58) (actual time=995.278..16737.223 rows=68442 loops=1)
              Recheck Cond: ((datadate >= '2013-10-01 00:00:00'::timestamp without time zone) AND (datadate <= '2015-09-01 00:00:00'::timestamp without time zone))
              Filter: (gvkey = ANY ('{...500}'::integer[]))
              Rows Removed by Filter: 5502370
              Heap Blocks: exact=35703
              ->  Bitmap Index Scan on csco_idesind_2008_2020_datadate_gvkey_idx  (cost=0.00..4705.91 rows=184935 width=0) (actual time=769.804..769.805 rows=5570812 loops=1)
                    Index Cond: ((datadate >= '2013-10-01 00:00:00'::timestamp without time zone) AND (datadate <= '2015-09-01 00:00:00'::timestamp without time zone))
  ->  Materialize  (cost=62049438.45..63733054.29 rows=336723168 width=30) (actual time=232312.818..345640.447 rows=301097183 loops=1)
        ->  Sort  (cost=62049438.45..62891246.37 rows=336723168 width=30) (actual time=232312.813..315589.341 rows=285480123 loops=1)
              Sort Key: i.coifnd_id
              Sort Method: external merge  Disk: 14937712kB
              ->  Seq Scan on csco_ifndq i  (cost=0.00..6301306.68 rows=336723168 width=30) (actual time=0.852..114092.114 rows=336723160 loops=1)
Planning Time: 0.364 ms
JIT:
  Functions: 15
  Options: Inlining true, Optimization true, Expressions true, Deforming true
  Timing: Generation 1.436 ms, Inlining 8.045 ms, Optimization 130.210 ms, Emission 64.295 ms, Total 203.985 ms
Execution Time: 389780.055 ms

1) почему Rows Removed by Filter: 5502370 осталось? Я предлагал изменить индексы, чтобы один из них (по идее, PK) начинался с пары datadate, gvkey - что с этой идеей?
2) "Но с таким хаком: создал временную таблицу" -- ну тогда уж лучше подумать о materialized view. Будет храниться, обновляться иногда (refresh .. concurrently; потребуется unique index), но при этом из неё читать можно будет очень быстро, если правильные индексы держать

2) да, темп это временное решение. Все же что будет лучше партиции или вью сделать?

Лучше бы Вы показали EXPLAIN (ANALYZE, BUFFERS, SETTINGS). ;)
И, возможно, даже оригинального запроса.
И, кстати, BETWEEN с timestamps (как и timestamp without time zone, как у Вас) использовать неправильно, вообще-то.
Раз https://wiki.postgresql.org/wiki/Don%27t_Do_This#Don.27t_use_BETWEEN_.28especially_with_timestamps.29 и два
https://wiki.postgresql.org/wiki/Don%27t_Do_This#Date.2FTime_storage