Re: Temporarily very slow planning time after a big delete - Mailing list pgsql-performance

From didier
Subject Re: Temporarily very slow planning time after a big delete
Date
Msg-id CAJRYxuJ6bUKHa3ykvuXQpvVX-ERjTmb7Kpj9rXjAf+tsCizk5w@mail.gmail.com
Whole thread Raw
In response to Re: Temporarily very slow planning time after a big delete  (Walter Smith <walter@carezone.com>)
List pgsql-performance


On Tue, May 21, 2019 at 8:27 PM Walter Smith <walter@carezone.com> wrote:
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 by date:

Previous
From: Walter Smith
Date:
Subject: Re: Temporarily very slow planning time after a big delete
Next
From: Peter Geoghegan
Date:
Subject: Re: Temporarily very slow planning time after a big delete