Re: Poor plan choice in prepared statement

Поиск
Список
Период
Сортировка
От david@lang.hm
Тема Re: Poor plan choice in prepared statement
Дата
Msg-id alpine.DEB.1.10.0901011222190.15026@asgard.lang.hm
обсуждение исходный текст
Ответ на Re: Poor plan choice in prepared statement  ("Guillaume Smet" <guillaume.smet@gmail.com>)
Ответы Re: Poor plan choice in prepared statement  ("Guillaume Smet" <guillaume.smet@gmail.com>)
Список pgsql-performance
On Thu, 1 Jan 2009, Guillaume Smet wrote:

> On Wed, Dec 31, 2008 at 5:01 PM, Alvaro Herrera
> <alvherre@commandprompt.com> wrote:
>> I think it has been shown enough times that the performance drop caused
>> by a worse plan can be orders of magnitudes worse than what's gained by
>> producing the plan only once.  It does not seem a bad idea to provide a
>> way to carry out only the parse phase, and postpone planning until the
>> parameters have been received.
>
> It's already done in 8.3 for unnamed plans, isn't it?

forgive my ignorance here, but if it's unnamed how can you reference it
later to take advantage of the parsing?

I may just be not understanding the terms being used here.

David Lang

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

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