Comment 22 for bug 276950

Our existing index gives a reasonable plan when changed to use a sort that uses the new index - and it should consistently get better results when the history is spread all over the place :

launchpad_qastaging=> explain analyze SELECT PackageUpload.archive,
       PackageUpload.changesfile,
       PackageUpload.date_created,
       PackageUpload.distroseries,
       PackageUpload.id,
       PackageUpload.pocket,
       PackageUpload.signing_key,
       PackageUpload.status
FROM PackageUpload
WHERE packageupload.distroseries = 104
  AND packageupload.archive IN (1, 534)
  AND packageupload.status IN (0)
ORDER BY distroseries desc, status desc, archive desc, PackageUpload.id DESC LIMIT 31
 OFFSET 0;
                                                                                QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Limit (cost=5400.68..5400.76 rows=31 width=36) (actual time=0.053..0.054 rows=1 loops=1)
   -> Sort (cost=5400.68..5404.61 rows=1571 width=36) (actual time=0.052..0.052 rows=1 loops=1)
         Sort Key: archive, id
         Sort Method: quicksort Memory: 25kB
         -> Index Scan using packageupload__distroseries__status__idx on packageupload (cost=0.00..5353.91 rows=1571 width=36) (actual time=0.032..0.034 rows=1 loops=1)
               Index Cond: ((distroseries = 104) AND (status = 0))
               Filter: (archive = ANY ('{1,534}'::integer[]))
 Total runtime: 0.116 ms
(8 rows)

(Note that strictly speaking this is a different sort order, but for the *specific* query in hand the only difference is that different archives will be grouped together in the output. I'm not sure why we have a limited query here on POST rather than a) get all or b) check for existence. Thats something for code spelunking.