 <p>Looking at your explain output, it looks like you're fetching most of the contents in the <code>documents</code> table so it's sensibly doing a sequential scan. Your rowcount estimates are reasonable, there doesn't seem to be any stats issue here.</p> <p>It's doing an external merge sort on disk, so you might see a significant increase in performance by increasing <code>work_mem</code> in the session, e.g.</p> <pre><code>SET work_mem = '12MB' </code></pre> <p>It's possible that an index on <code>(reference_id ASC, created_at DESC) WHERE (approved)</code> might be useful, since it'll allow results to be fetched in the order required.</p> <p>You could also experiment with adding <code>viewable_at</code> to the index. I think it might have to be the last column, but I'm not sure. Or even making it into a covering index by appending <code>viewable_at, id, content</code> and omitting the unnecessary <code>approved</code> column from the result set. This may permit an index-only scan, though with <code>DISTINCT ON</code> involved I'm not sure.</p>