PostgreSQL Query apparently not using multi-column index - postgresql

Question

Running a Heroku "Crane" PostgreSQL instance (Version 9.1.6)
I have a table with sales points; currency amounts are in local currency. I have a currency conversion table which contains the conversion factors between each currency and the euro, for any given day. I want to sum up the sales, returns, giveaways, and revenue (in dollars) for a given book (product). So I join to the currency conversion table once to convert the local currency to euros, and again to convert euros to dollars (remember that the rates are different based on the settlement date of the sale). So every sale point to be considered will be twice-joined to the currency conversions; experimentation has shown me that that is the main slow-down factor.
So I'm trying to optimize the following query:
SELECT
sum(paid_sales - paid_returns) as paid_units,
sum(royalty_amt*(uu_cc.rate / sp_cc.rate)) as royalty_amt,
sum(free_sales - free_returns) as free_units,
sum(lent_units) as lent_units
FROM "sales_points"
join currency_conversions sp_cc
on sp_cc.date = sales_points.settlement_date
and sp_cc.currency = sales_points.currency
join currency_conversions uu_cc
on uu_cc.date = sales_points.settlement_date
and uu_cc.currency = 'USD'
WHERE "sales_points"."book_id" = 234
LIMIT 1
I have created the following index:
CREATE INDEX index_currency_conversions_on_date_and_currency
ON currency_conversions
USING btree (date, currency COLLATE pg_catalog."default");
and yet EXPLAIN (after running ANALYZE) tells me it is doing a sequential scan of the currency conversions table. In case it matters, date is of type 'date' and currency is of type 'char var(255)'.
Here is the query plan:
Limit (cost=7285.04..7285.04 rows=1 width=39) (actual time=103.166..103.167 rows=1 loops=1)
Buffers: shared hit=916
-> Aggregate (cost=7285.04..7285.04 rows=1 width=39) (actual time=103.163..103.163 rows=1 loops=1)
Buffers: shared hit=916
-> Hash Join (cost=584.15..7256.29 rows=6388 width=39) (actual time=60.513..92.084 rows=5840 loops=1)
Hash Cond: (sp_cc.date = uu_cc.date)
Buffers: shared hit=916
-> Hash Join (cost=351.63..6985.45 rows=6388 width=39) (actual time=52.454..72.418 rows=5840 loops=1)
Hash Cond: ((sales_points.settlement_date = sp_cc.date) AND ((sales_points.currency)::text = (sp_cc.currency)::text))
Buffers: shared hit=763
-> Bitmap Heap Scan on sales_points (cost=54.09..6630.06 rows=6446 width=30) (actual time=0.912..7.020 rows=5840 loops=1)
Recheck Cond: (book_id = 234)
Buffers: shared hit=610
-> Bitmap Index Scan on index_sales_points_on_book_id (cost=0.00..53.77 rows=6446 width=0) (actual time=0.809..0.809 rows=6521 loops=1)
Index Cond: (book_id = 234)
Buffers: shared hit=22
-> Hash (cost=214.95..214.95 rows=20649 width=16) (actual time=51.502..51.502 rows=20649 loops=1)
Buckets: 4096 Batches: 1 Memory Usage: 968kB
Buffers: shared hit=153
-> Seq Scan on currency_conversions sp_cc (cost=0.00..214.95 rows=20649 width=16) (actual time=0.007..21.153 rows=20649 loops=1)
Buffers: shared hit=153
-> Hash (cost=225.27..225.27 rows=2071 width=12) (actual time=8.040..8.040 rows=2071 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 89kB
Buffers: shared hit=153
-> Seq Scan on currency_conversions uu_cc (cost=0.00..225.27 rows=2071 width=12) (actual time=0.021..5.963 rows=2071 loops=1)
Filter: ((currency)::text = 'USD'::text)
Buffers: shared hit=153
Total runtime: 103.306 ms
Does anyone know why it is not using my index?

Answer 1

The multi-column index is something of a mistake here. You probably want two separate indexes on the two columns since this gives the planner more flexibility.
Your current index cannot be used with your query since it requires querying on date from the table (the btree is first on date, secondarily on currency). If the columns were in the other order it might be useful but it could not be used where date would be more selective.
Your best option is to have separate indexes for the two fields. This way the planner can choose which index is expected to be more selective for the query at hand, rather than having to take or leave an index which may be of dubious value for a given query.
Also note that PostgreSQL can do bitmap index scans across multiple indexes, allowing it to use both indexes concurrently if necessary.