Re: RE: [PERFORM] Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: RE: [PERFORM] Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it.
Дата
Msg-id 6240.1375890794@sss.pgh.pa.us
обсуждение исходный текст
Ответ на RE: [PERFORM] Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it.  (<slapo@centrum.sk>)
Ответы Re: [PERFORM] RE: [PERFORM] Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it.  (<slapo@centrum.sk>)
Список pgsql-performance
<slapo@centrum.sk> writes:
> "Total runtime: 9.313 ms" in pgAdmin
> "Total runtime: 9.363 ms" in psql.
> But timing after the query finished was 912.842 ms in psql.

Well, that's the downside of increasing join_collapse_limit and
from_collapse_limit: you might get a better plan, but it takes a lot
longer to get it because the planner is considering many more options.

If you're sufficiently desperate, you could consider rewriting the query
so that its JOIN structure matches the join order that the planner chooses
at the high collapse_limit settings.  Then you can reduce the limits back
down and it'll still find the same plan.  This tends to suck from a query
readability/maintainability standpoint though :-(.

The prepared-query approach might offer a solution too, if the good plan
isn't dependent on specific parameter values.

            regards, tom lane


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

Предыдущее
От: Igor Neyman
Дата:
Сообщение: Re: Re: [PERFORM] Sub-optimal plan for a paginated query on a view with another view inside of it.
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Better performance possible for a pathological query?