Pagination with PostgreSQL 9.3: counting number of pages
Index definition
Your multicolumn index generally looks good. If all or most of your queries use order by score desc, id desc, it would be a bit more efficient to define it with matching sort order and a simpler condition:
CREATE INDEX prod_category_score_id ON products(category, score DESC, id DESC)
WHERE active;


WHERE active = TRUE is just a more complicated way of saying WHERE active.
While Index Scan Backward is practically as fast as a plain index scan, access is simpler with matching sort order in multicolumn index.

Why the extra Bitmap Heap Scan?
Due to the MVCC model of Postgres it needs to make sure that entries in the index are actually still alive in the table.
The planner method Index Scan works best for a small number of rows. Postgres takes each row pointer from the index and fetches the row from the heap (the table) sequentially, thereby also checking if the row is actually visible to the current transaction.
With a growing number of hits, this gets less effective. If multiple rows reside on the same data page, it's more efficient to collect tuples and visit the same page only once. That's what a Bitmap Index Scan does essentially (among other things).
When counting rows with count(*), Postgres wouldn't need data from the heap. But it still must verify that each tuple is visible and actually counts. The Wiki page about &quot;Slow counting&quot;.
Postgres 9.2 introduced Index Only Scans. If the &quot;visibility map&quot; says all tuples of a page are visible to all current transactions, Postgres does not have to visit the heap to verify. That would be faster for a query such as yours, that only counts a small percentage of rows, most efficiently determined by using the index.
Obviously, you have a lot of concurrent write operations. Or your autovacuum settings are not aggressive enough. Else, you might see a faster Index Only Scan.
The Postgres Wiki about that.