From: | "Dmitry E(dot) Oboukhov" <unera(at)debian(dot)org> |
---|---|
To: | pgsql-ru-general(at)postgresql(dot)org |
Subject: | Re: SPAM (5.7) [pgsql-ru-general] Re: [pgsql-ru-general] Запарил сверхинтеллект |
Date: | 2017-12-02 08:37:04 |
Message-ID: | 20171202083704.nrxh6owq2vnxbzsy@vdsl.uvw.ru |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-ru-general |
> Какие выставлены 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(at)debian(dot)org>
: :’ :
`. `~’ GPG key: 4096R/08EEA756 2014-08-30
`- 71ED ACFC 6801 0DD9 1AD1 9B86 8D1F 969A 08EE A756
From | Date | Subject | |
---|---|---|---|
Next Message | Максим Мохна | 2017-12-27 07:10:17 | server process was terminated by exception 0xC00000FD |
Previous Message | Nikolay Samokhvalov | 2017-12-01 15:49:12 | Re: select + insert |