Index usage on a temporary table
The choice between index scan and bitmap index scan is basically decided by how many rows per data page Postgres expects to retrieve - which depends on statistics about data distribution in the table and selectivity of your query predicates. And by the expected cost of random memory access - which is defined by cost settings, most prominently random_page_cost and effective_cache_size.
If Postgres expects to find enpugh rows on the same data page, it switches to bitmap index scan, which is more efficient for this kind of physical data distribution. (If most data pages are retrieved, a lowly sequential scan is faster anyway.) So even if columns and indexes of your two tables look all the same, you may still get these different query plans depending on data distribution and selectivity of your query predicates.

Optimizing queries on a range of timestamps (one column)
&quot;Recheck Cond:&quot; line in query plans with a bitmap index scan

But your tables are very different to begin with. mp_physical has much wider rows, so that only few rows are located on the same data page (default 8kb). This heavily favors index scans, since bitmap index scans won't buy much (if anything) even when retrieving a higher percentage of all rows.
Also, be aware that temporary tables are not covered by autovacuum and hence not analyzed automatically. You may have to do this manually to get accurate table statistics for the query planner to work with:
ANALYZE observations_optical_temp;


Are regular VACUUM ANALYZE still recommended under 9.1?