Re: Temporarily very slow planning time after a big delete

Поиск
Список
Период
Сортировка
От Walter Smith
Тема Re: Temporarily very slow planning time after a big delete
Дата
Msg-id CAOERZXg7zeHDUpVcfq2SUGYjEyZ-M6q6p3FJ8-5U+DUMHNNa9g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Temporarily very slow planning time after a big delete  (Peter Geoghegan <pg@bowt.ie>)
Ответы Re: Temporarily very slow planning time after a big delete
Re: Temporarily very slow planning time after a big delete
Список pgsql-performance
Дерево обсуждения
On Tue, May 21, 2019 at 11:17 AM Peter Geoghegan <pg@bowt.ie> wrote:
On Tue, May 21, 2019 at 11:16 AM Walter Smith <walter@carezone.com> wrote:
> It occurs to me that is a somewhat unusual index -- it tracks unprocessed notifications so it gets an insert and delete for every row, and is normally almost empty.

Is it a very low cardinality index? In other words, is the total
number of distinct keys rather low? Not just at any given time, but
over time?

Very low. Probably less than ten over all time. I suspect the only use of the index is to rapidly find the processed=false rows, so the notifiable_type value isn’t important, really. It would probably work just as well on any other column.

— Walter



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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: Temporarily very slow planning time after a big delete
Следующее
От: didier
Дата:
Сообщение: Re: Temporarily very slow planning time after a big delete