Search Postgresql Archives

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux