Re: Bad plan on a huge table query

Поиск
Список
Период
Сортировка
От Daniel Cristian Cruz
Тема Re: Bad plan on a huge table query
Дата
Msg-id CACffM9HB4syOdBVcVSet1RTJBic8MCK9bfmSoLpB681Z_5=UfQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Bad plan on a huge table query  (Daniel Cristian Cruz <danielcristian@gmail.com>)
Ответы Re: Bad plan on a huge table query
Список pgsql-general
I've reduced default_statistics_target to 200, and saw less nested loops.

I'm trying some changes to the query, but no better results.

The table presenca has 26 million rows. The table aula_confirmacao has 840 thousand rows.


2013/3/21 Daniel Cristian Cruz <danielcristian@gmail.com>
Hi,

I'm trying to figure out why does the planner found 1 row estimate using nested loops over a big table. There is no return from it:


It returns if disable nested loops, but the plan still poor:


I'm using PostgreSQL 9.2.3, default_statistics_target on 1000.

I can't remember what to make PostgreSQL sees a better estimate in the scan of aula_confirmacao and the join with presenca. I got rusty after a long time just doing modeling.

Does someone has some idea on that?

Thanks,
--
Daniel Cristian Cruz
クルズ クリスチアン ダニエル



--
Daniel Cristian Cruz
クルズ クリスチアン ダニエル

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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: Problem in "Set search path"
Следующее
От: Adrian Klaver
Дата:
Сообщение: Re: State of the art re: group default privileges