планы выполнения естественно разные, так как используются разные индексы. меня "напрягает" именно то, что до пересоздания индексов всё работает как и ожидаешь. И только после пересоздания всё начинает "косячить".

сейчас вернем

план запроса до пересоздания _byperiod:
https://explain.tensor.ru/archive/explain/898fe777dabcd3bec4e2ff246612c6f1:0:2020-05-25

план запроса после пересоздания _byperiod:
https://explain.tensor.ru/archive/explain/20aca0d4b6491cfa21f48c613d1daf29:0:2020-05-25

Только если у планов (того и другого) [очень] близкие оценки, по идее. Ну или с prepared statements могут быть всякие неочевидные проблемы.

> (последний создаваемый индекс является приоритетным)

Но именно такого быть не должно.

правильно ли я понимаю что порядок создания индексов тоже имеет существенное значение, даже если выполнение  плана с этим последним созланным будет дольше(дороже) чем с использованием ранее созданных индексов?

Подождите, почему он вообще должен иметь значение?

Ну и смотрите:

1. Nested Loop  (cost=33822.59..33825.37 rows=1 width=47) (actual time=13.577..15.041 rows=371 loops=1)
2. Nested Loop  (cost=33822.59..33825.37 rows=1 width=47) (actual time=20.039..1079.650 rows=371 loops=1)
Оценки вообще 1:1!

потому что именно после удаления и повторного создания этот индекс становится "последним созданным"

и именно после пересоздания индекса "ломается" план

Ещё раз, быть такого не должно. Если выполнение  плана с этим последним созданным будет дороже, выбираться должен какой-то другой план.

ничего другого с таблицей и СУБД не происходит, настройки не меняются, данные в таблицу не добавляются

значит и в ванильной версии есть ошибка(?), которая  вылазит именно при пересоздании индекса

Да Вы на оценки посмотрите — они идентичны. А выбор того или иного из планов с равной стоимостью зависит от "погоды на Марсе"... и почему нет? ;)

Да нет там никакой ошибки, скорее всего. Совпали оценки того и другого пути доступа — и что PostgreSQL должен с этим делать? ;)

если следовать этой логике то выполнение плана тоже должно тогда подчиняться "погоде на Марсе")), и каждый раз будет разный план, так?

но почему-то до пересоздания индеса ВСЕГДА выбирается план с использованием _bydims. А после пересоздания ВСЕГДА _byperiod

это если сравнивать 14 и 20, а если по верхней границе то там 15 и 59 уже есть разница

Нет. Выбор плана детерминированный, но как именно — теоретически неважно. Если оценки идеальные. ;)

> но почему-то до пересоздания индеса ВСЕГДА выбирается план с использованием _bydims. А после пересоздания ВСЕГДА _byperiod

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

Подождите, где Вы это видите? Я вижу, что оценки строго совпадают, как всего плана, так и самого "нижнего" узла:
1. Index Scan using _inforg4491_bydims4496 on _inforg4491 t6  (cost=0.56..2.79 rows=1 width=103) (actual time=0.002..0.003 rows=1 loops=371)
2. Index Scan using _inforg4491_byperiod on _inforg4491 t6  (cost=0.56..2.79 rows=1 width=103) (actual time=1.187..2.863 rows=1 loops=371)

А в остальном планы вообще идентичны (поэтому и стоимость одинаковая).

это я посмотрел не на кост, а на actual time. косты у всех одинаковы, да.