Re: Poor plan choice in prepared statement

Поиск
Список
Период
Сортировка
От Gregory Stark
Тема Re: Poor plan choice in prepared statement
Дата
Msg-id 877i5hotv6.fsf@oxford.xeocode.com
обсуждение исходный текст
Ответ на Re: Poor plan choice in prepared statement  (david@lang.hm)
Список pgsql-performance
david@lang.hm writes:

> since there is not a pre-parsed interface for queries, it may make sense to
> setup a way to have the query pre-parsed, but not pre-planned for cases like
> this.

What would be more interesting would be to have plans that take into account
the outlier values and have alternative plans for those values.


One aspect that hasn't been discussed here is whether it's only certain
outlier arguments that cause Postgres to choose the poor plan for you or
whether it always chooses it for all the sets of arguments you actually use.

If it's the former then it's possible you're only being bitten if the first
time you prepare the query happens to have one of these outlier set of
parameters. I forget what version this went in but I think it was before 8.2
that Postgres started using the first set of arguments seen to plan the query.
This is usually an improvement over just guessing but if that first set is
unusual it could lead to strange results.


--
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com
  Ask me about EnterpriseDB's On-Demand Production Tuning

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

Предыдущее
От: david@lang.hm
Дата:
Сообщение: Re: Poor plan choice in prepared statement
Следующее
От: "Guillaume Smet"
Дата:
Сообщение: Re: Poor plan choice in prepared statement