Re: More stable query plans via more predictable column statistics

Поиск
Список
Период
Сортировка
От Alex Shulgin
Тема Re: More stable query plans via more predictable column statistics
Дата
Msg-id CAM-UEKR6EUKT7E3JXqC5Txu4w1qxRbw+mEFAS0Mx4R9vP8oejw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: More stable query plans via more predictable column statistics  (Alex Shulgin <alex.shulgin@gmail.com>)
Ответы Re: More stable query plans via more predictable column statistics
Список pgsql-hackers
Дерево обсуждения
On Sun, Apr 3, 2016 at 3:43 AM, Alex Shulgin <alex.shulgin@gmail.com> wrote:

I'm not sure yet about the 1% rule for the last value, but would also love to see if we can avoid the arbitrary limit here.  What happens with a last value which is less than 1% popular in the current code anyway?

Tom,

Now that I think about it, I don't really believe this arbitrary heuristic is any good either, sorry.  What if you have a value that is just a bit under 1% popular, but is being used in 50% of your queries in WHERE clause with equality comparison?  Without this value in the MCV list the planner will likely use SeqScan instead of an IndexScan that might be more appropriate here.  I think we are much better off if we don't touch this aspect of the current code.

What was your motivation to introduce some limit at the bottom anyway?  If that was to prevent accidental division by zero, then an explicit check on denominator not being 0 seems to me like a better safeguard than this.

Regards.
--
Alex

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alex Shulgin
Дата:
Сообщение: Re: Add schema-qualified relnames in constraint error messages.
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Refer to a TOKEN_USER payload as a "token user, " not as a "user