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

Martijn van Oosterhout wrote:
> The problem AFAICS is that the planner is taking the results of two
> tables which are ordered by id and merging them. PostgreSQL doesn't
> have a Merge node type so it does this by concatentating the lists and
> sorting again.

That's definitely part of the problem.
The deeper problem though is that postgres should never consider the results
of the parent table at all. There is a check constraint on the inherited
table (cdr_id = 10554), so all rows should come from that table, right?

Or wait, maybe postgres considers rows from the parent table, because
the parent table has no check constraint. Unfortunately according to the
doc I cannot define a check constraint on the parent table, because it
would be inherited by the other tables.

There are problems with even simpler queries, e.g.
"select min(id) from call_sources where cdr_id = 10554;" is doing a
sequential scan. Even if it considers results from the parent table it should
combine the results of two index scans.