Re: Temporarily very slow planning time after a big delete

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:16:05
Message-ID: CAOERZXj4urxzKQF98hC-qPfsyL9ix9ucfKCH5iT3=unizwz1nA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Tue, May 21, 2019 at 11:15 AM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:

> On Tue, May 21, 2019 at 11:12 AM Walter Smith <walter(at)carezone(dot)com> wrote
> > I did a VACUUM overnight and got the following. The thing that stands
> out to me is that one index (index_unproc_notifications_on_notifiable_type)
> took 100x longer to scan than the others. That's not the index used in the
> slow query, though.
>
> What columns are indexed by
> index_unproc_notifications_on_notifiable_type, and what are their
> datatypes?
>

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.

Index "public.index_unproc_notifications_on_notifiable_type"
Column | Type | Definition
-----------------+------------------------+-----------------
notifiable_type | character varying(255) | notifiable_type
btree, for table "public.notifications", predicate (processed = false)

Thanks,
Walter

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Peter Geoghegan 2019-05-21 18:17:31 Re: Temporarily very slow planning time after a big delete
Previous Message Peter Geoghegan 2019-05-21 18:15:07 Re: Temporarily very slow planning time after a big delete