Re: Avoiding bad prepared-statement plans.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Avoiding bad prepared-statement plans.
Дата
Msg-id 8170.1267228986@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Avoiding bad prepared-statement plans.  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Avoiding bad prepared-statement plans.  (Mark Mielke <mark@mark.mielke.cc>)
Re: Avoiding bad prepared-statement plans.  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> Basically, what I really want here is some kind of keyword or other
> syntax that I can stick into a PL/pgsql query that requests a replan
> on every execution.

Wouldn't it be better if it just did the right thing automatically?

The sort of heuristic I'm envisioning would essentially do "replan every
time" for some number of executions, and give up only if it noticed that
it wasn't getting anything better than the generic plan.  So you'd have
a fixed maximum overhead per session when the custom plan was useless,
and the Right Thing when it wasn't.
        regards, tom lane


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

Предыдущее
От: Greg Smith
Дата:
Сообщение: Re: Hot Standby query cancellation and Streaming Replication integration
Следующее
От: Greg Smith
Дата:
Сообщение: Re: Hot Standby query cancellation and Streaming Replication integration