Really? From what I have done in writing my own code I have found hashing to be faster than a btree but then when I wrote my own hashing it was a specific type of key. Anyway I put in the tree indexes and I am still getting a seq scan.
Aggregate (cost=12.12..12.13 rows=1 width=0) -> Result (cost=0.00..12.12 rows=1 width=0) One-Time Filter: NULL::boolean -> Seq Scan on issuetracking (cost=0.00..12.12 rows=1 width=0) Filter: (((issue_target)::text = 'david'::text) OR ((manager)::text = 'david'::text))
The Postgres planner will choose what it thinks is the fastest plan. In this case, your table has only 1 row (?), so sequential scan will be fastest. You will want to load data into your table before doing benchmarking.
