4
Accepted answer
Low cardinality on the first column often hurts btree selectivity. A partial index WHERE status = 'pending' on created_at DESC is a much better fit for this query.
Added a btree on (status, created_at DESC). Query still does a seq scan on a 30M row table.
SELECT * FROM jobs WHERE status = 'pending' ORDER BY created_at DESC LIMIT 50;status cardinality is low, only 4 values. Should this be a partial index instead?
Accepted answer
Low cardinality on the first column often hurts btree selectivity. A partial index WHERE status = 'pending' on created_at DESC is a much better fit for this query.
Our dimension is slowly changing, does that change the join order?
Could you share a sketch of the salting logic?
Sometimes the real fix is a product change so you stop needing that join at all.
Sign in to reply.