| From: | Walter Smith <walter(at)carezone(dot)com> |
|---|---|
| To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
| Cc: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-performance(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Temporarily very slow planning time after a big delete |
| Date: | 2019-05-21 18:26:49 |
| Message-ID: | CAOERZXg7zeHDUpVcfq2SUGYjEyZ-M6q6p3FJ8-5U+DUMHNNa9g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Tue, May 21, 2019 at 11:17 AM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> On Tue, May 21, 2019 at 11:16 AM Walter Smith <walter(at)carezone(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | didier | 2019-05-21 18:32:06 | Re: Temporarily very slow planning time after a big delete |
| Previous Message | Peter Geoghegan | 2019-05-21 18:17:31 | Re: Temporarily very slow planning time after a big delete |