| From: | didier <did447(at)gmail(dot)com> |
|---|---|
| To: | walter(at)carezone(dot)com |
| Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, 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:32:06 |
| Message-ID: | CAJRYxuJ6bUKHa3ykvuXQpvVX-ERjTmb7Kpj9rXjAf+tsCizk5w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Tue, May 21, 2019 at 8:27 PM Walter Smith <walter(at)carezone(dot)com> wrote:
> 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 | Peter Geoghegan | 2019-05-21 18:36:30 | Re: Temporarily very slow planning time after a big delete |
| Previous Message | Walter Smith | 2019-05-21 18:26:49 | Re: Temporarily very slow planning time after a big delete |