Ребята, подскажите, не нашел в доках. Ситуация такая
есть таблица T1 с полем date на которое навесил индекс date_idx

select * from schema.T1 where c_date>current_date использует индекс date_idx

Цепляю эту таблицу как внешнюю на другом сервере
Этот же запрос уже индекс не использует.
select * from foreign_schema.T1 where c_date>current_date

Где можно про это почитать подскажите пожалуйста!

Melkij,

date 'now' это тоже не константа. Это же вычисляемое значение!? абсолютно такая же

Дело в в неиспользовании индексов. Сталкиваюсь уже не первый раз поэтому это точно. Вопрос почему и что можно сделать.

Один и тот же запрос

План первого запроса
Buffers: shared hit=5 read=2
-> Index Scan using idx_date on T1 (cost=0.43..576.83 rows=18119 width=44) (actual time=16.097..16.101 rows=10 loops=1)
Index Cond: (c_date > '2021-04-09'::date)
Buffers: shared hit=5 read=2
Planning time: 0.981 ms
Execution time: 16.134 ms

План второго
-> Foreign Scan on T1 (cost=100.00..140.11 rows=401 width=44) (actual time=13029.820..81112.138 rows=10 loops=1)
Filter: (c_date > '2021-04-09'::date)
Rows Removed by Filter: 8215940
Planning Time: 1.345 ms
Execution Time: 81159.278 ms

в первом посте я написал какой первый, а какой второй запрос. А во втором посте привел их планы.

В плане видно, что не работает по индексу. Хоть так date 'now' хоть так '2021-04-09'::date

ну планы и время идентичные почти

current_date Index Cond: (date_end > ('now'::cstring)::date)

date 'now' Index Cond: (date_end > '2021-04-09'::date)

--какой запрос отправляет fdw
fdw а где это посмотреть?

Melkij,

да, стоит postgres_fdw. Версия PG 12.5

Maxim Boguk,

делаю лимит 10, иначе запрос висит вечно

1)
Limit (cost=100.00..100.99 rows=10 width=4) (actual time=5530.590..36439.849 rows=10 loops=1)
Output: id
-> Foreign Scan on t1 (cost=100.00..196.06 rows=975 width=4) (actual time=5530.588..36439.842 rows=10 loops=1)
Output: id
Filter: (c_date > '2021-04-09'::date)
Rows Removed by Filter: 8215940
Remote SQL: SELECT id, c_date FROM t1
Planning Time: 1.542 ms
Execution Time: 36517.025 ms

2)timestamptz NOT NULL,
3)после создания сервера делал
ALTER SERVER db_srv_load
OPTIONS (ADD use_remote_estimate 'true');
4)да

Maxim Boguk,

Огромное спасибо! Все понял.

Maxim Boguk,

Максим, не подскажете еще

Есть таблица с индексом по полю n_id_form_version int4 NOT NULL

select * from ft_frm where n_id_form_version = 20577291

Запрос на самом сервере
Index Scan using ft_frm_form_id on ft_frm fd (cost=0.71..14918.00 rows=613688 width=78) (actual time=0.076..8.722 rows=35679 loops=1)
Output: n_id, n_id_form_version, n_id_left_header, n_id_top_header, n_val, s_val, d_val, n_err, id_row, n_id_new
Index Cond: (fd.n_id_form_version = 20577291)
Planning time: 19.210 ms
Execution time: 9.983 ms


Запрос через fdw
Foreign Scan on ft_frm fd (cost=100.71..27291.76 rows=613688 width=78) (actual time=1.478..160.303 rows=35679 loops=1)
Output: n_id, n_id_form_version, n_id_left_header, n_id_top_header, n_val, s_val, d_val, n_err, id_row, n_id_new
Remote SQL: SELECT n_id, n_id_form_version, n_id_left_header, n_id_top_header, n_val, s_val, d_val, n_err, id_row, n_id_new FROM ft_frm WHERE ((n_id_form_version = 20577291))
Planning Time: 44.055 ms
Execution Time: 161.871 ms


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

Maxim Boguk, Большое спасибо за ответ.

Я не пытаюсь сделать, чтоб мне все разжевали и на тарелку положили, просто не всегда можно предположить, что ответ потребует много временных затрат. В данном случае думал будет в духе "смотри в сторону .." или "для fdw это нормально".
Конечно развернутые ответы это круто, огромное спасибо.

Maxim Boguk, продолжу исследовать тему, хотелось бы в итоге сделать для себя более менее однозначные выводы.
Вообще надо 5ТБ данных переложить из одной БД в другую БД с абсолютно другой схемой данных на другом сервере и может оказаться, что fdw вообще плохой вариант для этих целей.