Re: FE/BE protocol vs. parameterized queries

Поиск
Список
Период
Сортировка
От Csaba Nagy
Тема Re: FE/BE protocol vs. parameterized queries
Дата
Msg-id 1157617921.2402.35.camel@coppola.muc.ecircle.de
обсуждение исходный текст
Ответ на Re: FE/BE protocol vs. parameterized queries  (Michael Paesold <mpaesold@gmx.at>)
Список pgsql-hackers
> Although I don't have a clear opinion myself, I sometimes read on this list 
> that people are using prepared statements to get safe, stable plans, i.e. 
> plans that don't depend on the specific parameter input.

I definitely want the possibility of getting stable plans. That's only
possible if the planner does NOT take into account any parameter values.
If the statistics get quicker out of date than it's practical to run
analyze, but the plans would stay stable, it's better not to have
parameter values taken into account.
> If you change that, I don't think they will be happy at all. I suggest 
> leaving it as-is for 8.2. I think the user (i.e. driver) should be able to 
> tell the backend, if they want planning for the first bind, or right at 
> prepare.

That would be nice. We would probably use all 3 forms: - unnamed statement: prepare based on constant parameters; -
namedstatement: prepare based on the first set of parameter values; - named statement: prepare generic plan without
consideringparameter
 
values;

Cheers,
Csaba.




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

Предыдущее
От: Michael Paesold
Дата:
Сообщение: Re: FE/BE protocol vs. parameterized queries
Следующее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: UUID/GUID discussion leading to request for hexstring bytea? (was: Re: TODO: GUID datatype)