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

Поиск
Список
Период
Сортировка
От Stephen Friedrich
Тема Re: Partitioning: Planner makes no use of indexes on inherited
Дата
Msg-id 43CE19EF.2070701@fortis-it.de
обсуждение исходный текст
Ответ на Re: Partitioning: Planner makes no use of indexes on inherited  (Martijn van Oosterhout <kleptog@svana.org>)
Ответы Re: Partitioning: Planner makes no use of indexes on inherited  (Martijn van Oosterhout <kleptog@svana.org>)
Список 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 по дате отправления:

Предыдущее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: Partitioning: Planner makes no use of indexes on inherited
Следующее
От: Együd Csaba
Дата:
Сообщение: Error Starting postmaster.exe (8.1.2-1) on XP - GPF