Home/ Questions/Q 6856155
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-27T01:50:58+00:00

I’ve had a query that has been running fine for about 2 years. The

  • 0

I’ve had a query that has been running fine for about 2 years. The database table has about 50 million rows, and is growing slowly. This last week one of my queries went from returning almost instantly to taking hours to run.

Rank.objects.filter(site=Site.objects.get(profile__client=client, profile__is_active=False)).latest('id')

I have narrowed the slow query down to the Rank model. It seems to have something to do with using the latest() method. If I just ask for a queryset, it returns an empty queryset right away.

#count returns 0 and is fast
Rank.objects.filter(site=Site.objects.get(profile__client=client, profile__is_active=False)).count() == 0
Rank.objects.filter(site=Site.objects.get(profile__client=client, profile__is_active=False)) == [] #also very fast

Here are the results of running EXPLAIN. http://explain.depesz.com/s/wPh

And EXPLAIN ANALYZE: http://explain.depesz.com/s/ggi

I tried vacuuming the table, no change. There is already an index on the “site” field (ForeignKey).

Strangely, if I run this same query for another client that already has Rank objects associated with her account, then the query returns very quickly once again. So it seems that this is only a problem when their are no Rank objects for that client.

Any ideas?

Versions:
Postgres 9.1,
Django 1.4 svn trunk rev 17047

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Well, you’ve not shown the actual SQL, so that makes it difficult to be sure. But, the explain output suggests it thinks the quickest way to find a match is by scanning an index on “id” backwards until it finds the client in question.

    Since you said it has been fast until recently, this is probably not a silly choice. However, there is always the chance that a particular client’s record will be right at the far end of this search.

    So – try two things first:

    1. Run an analyze on the table in question, see if that gives the planner enough info.
    2. If not, increase the stats (ALTER TABLE … SET STATISTICS) on the columns in question and re-analyze. See if that does it.

    http://www.postgresql.org/docs/9.1/static/planner-stats.html

    If that’s still not helping, then consider an index on (client,id), and drop the index on id (if not needed elsewhere). That should give you lightning fast answers.

    • 0