Re: Please help with a slow query: there are millions of records, what can we do?

From: Pat Maddox <pat(at)adorable(dot)io>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Please help with a slow query: there are millions of records, what can we do?
Date: 2017-03-22 15:07:46
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-performance

> On Mar 8, 2017, at 11:00 AM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> You could try a partial index on:
> (account_id, completed_at desc, taskable_name, position, assigned_to_user_id) where "tasks"."archived" != 't' AND "tasks"."complete" = 't'
> Also, the poor estimate of the number of rows on your scan of index_permissions_on_user_id_and_object_id_and_object_type suggests that you are not analyzing (and so probably also not vacuuming) often enough.

Thanks for this. So here’s a quick update…

I removed all the indexes that are there and added one on:

(account_id, taskable_type, taskable_id, assigned_to_user_id, archived, complete, completed_at, due_on)

We search for tasks that are complete or incomplete, so we wouldn’t want a partial index there… but I _think_ changing the index to be partial where archived != ’t’ would be beneficial; I’ll have to look. As of today, only about 10% of the tasks are archived=’t’ – though that’s still ~1 million rows at this point.

That helped the query plans big time, and adding more RAM so the indexes fit in memory instead of swapping led to major improvements.

So thank you for the suggestions :)

I’ve manually vacuumed and analyzed a few times, and the estimates are always pretty far off. How do you suggest increasing the stats for the table? Just increase it, vacuum, and see if the stats look better?


In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Pietro Pugni 2017-03-24 09:58:08 Postgres not using all RAM (Huge Page activated on a 96GB RAM system)
Previous Message Claudio Freire 2017-03-22 01:58:58 Re: Optimizing around retained tuples