Tom Lane <t...@sss.pgh.pa.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
