Postgres compound index not delivering expected improvements
Maybe the compound index isn't used because it thinks the single-column index is selective enough that there is no point in adding more selectivity.  The way to find out is by seeing the results of EXPLAIN (ANALYZE, BUFFERS) SELECT ...

You can disable the indexes by dropping them inside a transaction you later rollback:

BEGIN;
DROP index i1,i2;
EXPLAIN (ANALYZE, BUFFERS) SELECT....;
ROLLBACK;


Rolling back the index-drop will be nearly instantaneous, it doesn't have to rebuild them.  If you run it in production, be aware that the table will be AccessExclusive locked for the duration of the transaction.

You also don't have to experiment with the full 600 million rows.  6 millions is probably plenty to get some valid insight:

create table foo_exp as select * from foo where random()&lt;0.01;
vacuum analyze foo_exp
create index...;
explain (analyze, buffers) ...;


The order in the WHERE clause doesn't matter, but the order in the btree index does.  The equality-constrained column should be the leading column in the index, with the range-constrained column after.

For asking performance questions, see https://dba.stackexchange.com/tags/postgresql-performance/info