Maxim Boguk7)а да и если база у вас на ssd то random_page_cost=1 seq_page_cost=1 (так оно ближе к реальности будет)


Тогда уж лучше их еще больше уменьшать до 0.1 и / или увеличивать cpu_tuple_cost, потому как нормальная ssd по скорости недалеко ушла от памяти, и index scan от seq scan соответственно не очень сильно отличается...

это проистекает из того, что основные проблемы в 1С -- работа с только что заполненными в транзакции и непроанализированными времянками (или даже постоянными, но с тем же результатом), оптимизатор ждёт 1 записи -- получает 100000, и бегает по ним в нестед лупе 3-й вложенности с утра и до упора.
По крайней мере раньше было так.
Потом они, якобы пропатчили пж (по части статистики в транзакциях). кажется от ~~ Pg.8.3.1С должен уже что-то с их т.з. уметь.


Странная теория, потому как проще запустить ANALYZE после заполнения временной таблицы (в транзакции это позволяется), чем патчить PostgreSQL для этого.

Полагаю enable_nestloop помогает, потому как 1С генерит достаточно подзапросов для работы с регистрами на дату, а в случаях с подзапросами (особенно такими) postgres конкретно косячит со статистикой (в сторону уменьшения) и вероятность свалиться в nested loop 2-х таблиц по 100К очень большая (тем более, что не уверен, что 1С всегда корректно выполняет predicate pushdown, все же MS SQL его частично умеет делать, а 1С писался изначально под MS SQL, поэтому вероятно они не сильно этим заморачивались). И возможно для решения этой проблемы (а также predicate pushdown) PostgreSQL и патчили. Кстати самому интересно можно ли где-то посмотреть что же они именно там патчили? :)

Мы тоже enable_nestloop раньше использовали, только конечно хитрее - ставили timeout на большинство запросов и если запрос не успевал выключали enable_nestloop. (конечно кэшируя это все, с disabled nestedloop тоже ставился timeout и если запрос не успевал выполнится, увеличивали timeout и опять включали nested loop и т.п.). Но вообще enable_nestloop мина замедленного действия, так как по сути выключает использование индексов, а значит СУБД будет всегда бегать целиком по используемым таблицам. Поэтому сейчас перешли на более эффективную стратегию, материализация подзапросов при необходимости (уже ессно после predicate pushdown и с ANALYZE результата), и только уже в самом крайнем случае (когда не осталось подзапросов) отключение enable_nestloop.

qwwq,

Вы сейчас другую проблему описали. Что если мы в маленькую таблицу записали дохрена данных, то у нее нужно пересчитать статистику, то есть выполнить ANALYZE. А этот ANALYZE ессно учитывает только закоммиченные транзакции (чтобы чужим запросам "не мешать", хотя если честно не уверен что это так, надо проверить). Но в любом случае это все не касается временных таблиц (они отлично пересчитываются ANALYZE'ом).

Ну и описанный вами случай ОЧЕНЬ редкий, так как планировщик не сильно умный и смотрит в основном везде на общее кол-во. И если таблица "прожила какое-то время", изменения в ней как правило не критичные для планировщика. Другое дело что у вас возможно проблема была в том, что для индекса хранится диапазон значений, и у вас условие field = значение за пределами диапазона, и СУБД начинает думать что статистика 0, но как я уже написал это очень редкий случай, и enable_nestloop может навредить еще больше (так как индекс юзаться не будет).

FAMxКонфигурация 1с с которой возникают сложности практически стандартная УТ редакция 10.3 платформа 8.3.5.1119

А объясните, зачем вы вообще PostgreSQL ставите? Эта СУБД требует более тонкой работы с запросами, в отличии от MS SQL, которая некоторые вещи прощает. И у 1С все писалось под MS SQL.

Денег жалко? Так вы же лицензии 1С купили, а они дороже лицензий MS SQL + винды.