Thread: [pgsql-ru-general] Re: [pgsql-ru-general] Запарил сверхинтеллект
>
> но остаются вопросы:
>
> когда запросов таких станет много разных: сверхинтеллект планировщика
> будет меня снова побеждать или нет?
>
Какие выставлены random_page_cost & seq_page_cost?
[pgsql-ru-general] Re: SPAM (5.7) [pgsql-ru-general] Re: [pgsql-ru-general] Запарил сверхинтеллект
From
"Dmitry E. Oboukhov"
Date:
> Какие выставлены random_page_cost & seq_page_cost? дефолтные 4 и 1. seq_page_cost в данной проблеме вроде роли не играет. поставить random_page_cost в 400 попробовать? Вопрос только как это аукнется на других запросах/таблицах. в приведенном EXPLAIN получается следующее: размер таблицы - 80 млн, он берет выборку 4 млн (== 0.05) и перемножает с выборкой 0.3 млн (0.004). Возможно это из за того что коэффициенты отношений маленькие у него получается и он считает что перемножение будет дешевым? и еще, по моему данная проблема реже проявляется на НЕчастичных индексах. То есть я об эту проблему разбиваю нос обычно когда построен именно ЧАСТИЧНЫЙ индекс специально для запроса. вот условие WHERE status IN () у нас сокращает 80 млн до 2 тыс. Поэтому индекс частичный логичен вроде. Но вот именно частичные индексы Pg почему-то иногда отбрасывает и лезет в пересечение полных. :( -- . ''`. Dmitry E. Oboukhov <unera@debian.org> : :’ : `. `~’ GPG key: 4096R/08EEA756 2014-08-30 `- 71ED ACFC 6801 0DD9 1AD1 9B86 8D1F 969A 08EE A756