Re: Avoiding bad prepared-statement plans.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Avoiding bad prepared-statement plans.
Дата
Msg-id 16678.1267161116@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Avoiding bad prepared-statement plans.  (Alex Hunsaker <badalex@gmail.com>)
Ответы Re: Avoiding bad prepared-statement plans.  (Alex Hunsaker <badalex@gmail.com>)
Re: Avoiding bad prepared-statement plans.  (Mark Mielke <mark@mark.mielke.cc>)
Список pgsql-hackers
Alex Hunsaker <badalex@gmail.com> writes:
> I did seem to miss the part where everyone thinks this is a crock...
> But I don't remember seeing numbers on parse time or how much
> bandwidth this would potentially save.  People seem to think it would
> be a big savings for just those 2 reasons?  Or did I miss some other
> benefit?

Uh, no, this isn't about saving either parse time or bandwidth.
The discussion is about when to expend more planning time in hopes
of getting better plans.
        regards, tom lane


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: A thought on Index Organized Tables
Следующее
От: Takahiro Itagaki
Дата:
Сообщение: code cleanup: ss_currentScanDesc