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 по дате отправления: