On Tue, May 21, 2019 at 11:17 AM Peter Geoghegan wrote:
> On Tue, May 21, 2019 at 11:16 AM Walter Smith 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 emp
On Tue, May 21, 2019 at 11:15 AM Peter Geoghegan wrote:
> On Tue, May 21, 2019 at 11:12 AM Walter Smith 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 long
On Mon, May 20, 2019 at 7:15 PM David Rowley
wrote:
> It would be good if you could confirm the problem is resolved after a
> vacuum. Maybe run VACUUM VERBOSE on the table and double check
> there's not some large amount of tuples that are "nonremovable".
>
As I say, the problem resolved itself
Tom Lane writes:
>I'm assuming your problem
>query involved a join on the indexed column --- whether or not the
>final plan did a mergejoin, the planner would consider this
There's no join -- the query is
SELECT "notifications".*
FROM "notifications"
WHERE "notifications"."person_id" = ? AND
I'm so sorry -- I meant to give the version, of course. It's 9.6.13.
Thanks,
Walter
On Mon, May 20, 2019 at 6:05 PM Tom Lane wrote:
> Walter Smith writes:
> > Today we deleted about 15 million rows in one transaction from this
> table.
> > Immediately afterwards,
We had a mysterious (to us) slowdown today that I'm hoping someone can
explain just based on PG's principles of operation. It got better by itself
so it seems like it was "normal" behavior -- I just don't know what
behavior it was exhibiting.
We have a table of user notifications containing about
