Re: Partitioning: Planner makes no use of indexes on inherited

> Hmm - looking at it, this seems the case. Directly querying the
> partition it uses the index but estimates a cost of:
>   cost=0.00..23510.68 rows=575532 width=8907)
> The seq-scan says it has a cost of:
>   cost=0.00..20737.15 rows=575532 width=8907
>
> Could you issue "set enable_seqscan=off" and then show explain analyse
> on the second query again?

That doesn't make a big difference:
Limit  (cost=23365451.30..23365453.80 rows=1000 width=13436)
   ->  Sort  (cost=23365451.30..23366890.13 rows=575533 width=13436)
         Sort Key: this_.id
         ->  Result  (cost=0.00..23313.51 rows=575533 width=13436)
               ->  Append  (cost=0.00..23313.51 rows=575533 width=13436)
                     ->  Index Scan using call_source_cdr_index on call_sources this_  (cost=0.00..4.82 rows=1
width=13436)
                           Index Cond: (cdr_id = 10554)
                     ->  Index Scan using call_source_10554_cdr_index on call_sources_10554 this_  (cost=0.00..23308.68
rows=575532width=8907) 
                           Index Cond: (cdr_id = 10554)

IMHO the problem is that this should not be done:
   ->  Sort  (cost=23365451.30..23366890.13 rows=575533 width=13436)
         Sort Key: this_.id
because there is an index on the id column of the inherited table, so it
should be used as it is when querying the inherited table directly:
   ->  Index Scan using call_source_10554_id_index on call_sources_10554 this_  (cost=0.00..23510.68 rows=575532
width=8907)
         Filter: (cdr_id = 10554)