All of this is **unrelated to inheritance and partitioning**. It's about indexing and query plans in general.

The row size is much bigger for your second try: `width=157` vs. `width=46`. Postgres will even *more readily* use an index for wider rows. Possible reasons for the unexpected sequential scan include:

- You have substantially fewer rows in your tables for the second test as indicated by planner estimates: `rows=143` vs. `rows=357`. It does not pay to look up an index for only few rows to sort.

- Or statistics are outdated leading to misguided planner estimates (Postgres only *thinks* there would be fewer rows).

- The index size may have been bloated as a side-effect of rewriting the tables. `REINDEX` or `VACUUM FULL` would repair that.

Run `ANALYZE` on all involved tables and try again - with the same number of rows in all tables. You should see bitmap index scans again. If the phenomenon persists, provide the output of `EXPLAIN (ANALYZE, BUFFERS)`, not just `EXPLAIN`.

###After question update
As long as you read the *whole table*, an index is of limited use. If you query a **single table** with a matching index, so that readily sorted rows can be read from the index and Postgres can *skip the sort step altogether*, you'll see an **index scan**.

That's not possible when multiple tables have to be combined. This [**SQL fiddle**][1] with 10k rows per child and valid statistics shows **bitmap index scans** as expected. After repeating the query a couple of times (as soon as the whole table is cached), Postgres may skip the index and switch to **sequential scans**, which have become cheaper now.

Postgres is obviously not smart enough to understand the mutually excluding check constraints, which would allow to append readily sorted results from each table *as is*. You *could* force that by manually instructing it:

    (SELECT * FROM test2_20150812 ORDER BY ts DESC)
    UNION ALL
    (SELECT * FROM test2_20150811 ORDER BY ts DESC);

However, Postgres should be smart enough to use **Merge Append** (cheap method to combine pre-sorted sets). In my local tests on PostgreSQL **9.4** I actually see **index scans** on each partition, combined with **Merge Append**. That plan is better, but it's not that much faster than sequential scans because, remember!, as long as you read the *whole table*, an index is of limited use.

    'QUERY PLAN'
    'Merge Append  (cost=0.73..16866.41 rows=200001 width=45)'
    '  Sort Key: test.ts'
    '  ->  Index Scan Backward using test_ts_idx on test  (cost=0.13..8.14 rows=1 width=528)'
    '        Index Cond: (ts >= '2015-08-11 00:00:00'::timestamp without time zone)'
    '  ->  Index Scan Backward using test_20150811_ts_idx on test_20150811  (cost=0.29..6594.01 rows=100000 width=45)'
    '        Index Cond: (ts >= '2015-08-11 00:00:00'::timestamp without time zone)'
    '  ->  Index Scan Backward using test_20150812_ts_idx on test_20150812  (cost=0.29..6594.29 rows=100000 width=45)'
    '        Index Cond: (ts >= '2015-08-11 00:00:00'::timestamp without time zone)'

I don't get the same plan with Postgres 9.3 (testing on sqlfiddle). Must be a limitation of pg 9.3. (?)

But since you are using the **outdated version 9.0**, none of that is available to you.  
[Merge Append was introduced with 9.1.][2]

You get more interesting results when limiting the result to few rows. `varchar(15)` or `varchar(255)` has very little impact on the query plan. The wider type favors indexes some more.

[Your added fiddle with some more test queries.][3]

About testing indexes on SQL Fiddle:

- http://dba.stackexchange.com/questions/99323/postgresql-partial-index-unused-when-created-on-a-table-with-existing-data/99324#99324


  [1]: http://sqlfiddle.com/#!15/3aa47/1
  [2]: http://www.postgresql.org/message-id/flat/CABRT9RBbqEAZ37JMLq4cVTEJ5zTnzSFGBiXNZg-S6ctFSig+[email protected]#CABRT9RBbqEAZ37JMLq4cVTEJ5zTnzSFGBiXNZg-S6ctFSig+[email protected]
  [3]: http://sqlfiddle.com/#!15/53918/19