Re: Problem with planner choosing nested loop

Поиск
Список
Период
Сортировка
От Rodrigo E. De León Plicet
Тема Re: Problem with planner choosing nested loop
Дата
Msg-id a55915760804021157i5176407bld4e3b07ba6d4184d@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Problem with planner choosing nested loop  (Alex Solovey <a.solovey@gmail.com>)
Ответы Re: Problem with planner choosing nested loop
Список pgsql-general
On Wed, Apr 2, 2008 at 1:20 PM, Alex Solovey <a.solovey@gmail.com> wrote:
>  In this simple (which means "reduced") test database, yes. But the actual
> table "foo" in production database:
>
>  1. partitioned, with 50+ partitions
>  2. heavily updated (and indexes make it slow)
>  3. has more fields like bar_id
>
>  We had indexes on several fields based on typical access patterns, but
> after "foo" grew to a certain size (many gigabytes), sequential scans on
> selected partitions became the only feasible solution.
>  We can fix this particular query with an index, but the more general
> problem with planner choosing multiple scans over big table due to wrong
> estimate of results from the small table, remains.

Then provide actual DDL plus the production EXPLAIN ANALYZE output and
post it, maybe one of the Postgres gurus can help.

Good luck.

В списке pgsql-general по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: (FAQ?) JOIN condition - 'WHERE NULL = NULL'
Следующее
От: Alex Solovey
Дата:
Сообщение: Re: Problem with planner choosing nested loop