Re: Avoiding bad prepared-statement plans.

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Avoiding bad prepared-statement plans.
Дата
Msg-id 603c8f071003022113y6f78f7aete88e28c9f2d6a0c@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Avoiding bad prepared-statement plans.  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
On Tue, Mar 2, 2010 at 6:54 PM, Bruce Momjian <bruce@momjian.us> wrote:
> Robert Haas wrote:
>> > Adding SQL to indicate whether it should be re-planned or not is completely
>> > unappealing. If I could change the code, today, I'd just turn off or choose
>> > not to use PREPARE/EXECUTE. Today, PREPARE/EXECUTE seems like it should
>> > always be considered slower unless one can prove it is actually faster in a
>> > specific case, which is the exact opposite of what people expect.
>>
>> I don't really understand most of what you're saying here, but there's
>> definitely some truth to your last sentence.  This has easily got to
>> be one of the top ten questions on -performance.
>
> It seems it is the problem everyone knows about but no one fixes.  :-(

I'd work on it, but Tom doesn't like my proposed fix.  *shrug*

...Robert


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

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Instead of trying (and failing) to allow <
Следующее
От: Robert Haas
Дата:
Сообщение: Re: renameatt() can rename attribute of index, sequence, ...