[pgsql-ru-general] Re: SPAM (5.7) [pgsql-ru-general] Re: [pgsql-ru-general] Запарил сверхинтеллект - Mailing list pgsql-ru-general

From Dmitry E. Oboukhov
Subject [pgsql-ru-general] Re: SPAM (5.7) [pgsql-ru-general] Re: [pgsql-ru-general] Запарил сверхинтеллект
Date
Msg-id 20171202083704.nrxh6owq2vnxbzsy@vdsl.uvw.ru
Whole thread Raw
In response to [pgsql-ru-general] Re: [pgsql-ru-general] Запарил сверхинтеллект  (Nikolay Samokhvalov <samokhvalov@gmail.com>)
List 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@debian.org>
: :’  :
`. `~’               GPG key: 4096R/08EEA756 2014-08-30
  `- 71ED ACFC 6801 0DD9 1AD1  9B86 8D1F 969A 08EE A756

pgsql-ru-general by date:

Previous
From: Nikolay Samokhvalov
Date:
Subject: Re: [pgsql-ru-general] select + insert
Next
From: "Oleg Y. Danilkiff"
Date:
Subject: Re: server process was terminated by exception 0xC00000FD