From: | Walter Smith <walter(at)carezone(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
Cc: | pgsql-performance(at)lists(dot)postgresql(dot)org |
Subject: | Re: Temporarily very slow planning time after a big delete |
Date: | 2019-05-21 02:12:05 |
Message-ID: | CAOERZXje4G37KTPzQ-s-ar0mH4HG8ZVsk0ZDBmQdDiPnyOznuQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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
"notifications"."app_category" = ? AND
(id > ?)
ORDER BY created_at DESC
LIMIT ?
And the whole query plan is one step:
Index Scan using index_notifications_on_person_id_and_created_at on
notifications (cost=0.57..212.16 rows=52 width=231)
>Subsequent vacuuming would eventually delete the dead index entries
>and return things to normal; although usually the performance comes
>back all-of-a-sudden at the next (auto)VACUUM of the table. So I'm
>a bit intrigued by your seeing it "gradually" improve. Maybe you
>had old open transactions that were limiting VACUUM's ability to
>remove rows?'
We shouldn't have any long-running transactions at all, certainly not open
for a couple of hours.
Thanks,
Walter
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2019-05-21 02:15:09 | Re: Temporarily very slow planning time after a big delete |
Previous Message | Walter Smith | 2019-05-21 02:04:44 | Re: Temporarily very slow planning time after a big delete |