Re: Partitioning: Planner makes no use of indexes on inherited - Mailing list pgsql-general

From Stephen Friedrich
Subject Re: Partitioning: Planner makes no use of indexes on inherited
Date
Msg-id 43CE19EF.2070701@fortis-it.de
Whole thread Raw
In response to Re: Partitioning: Planner makes no use of indexes on inherited  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: Partitioning: Planner makes no use of indexes on inherited
List pgsql-general
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.

pgsql-general by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: Partitioning: Planner makes no use of indexes on inherited
Next
From: Együd Csaba
Date:
Subject: Error Starting postmaster.exe (8.1.2-1) on XP - GPF