Re: Avoiding bad prepared-statement plans.

Поиск
Список
Период
Сортировка
От Jeroen Vermeulen
Тема Re: Avoiding bad prepared-statement plans.
Дата
Msg-id 4B71674F.6030505@xs4all.nl
обсуждение исходный текст
Ответ на Avoiding bad prepared-statement plans.  (Jeroen Vermeulen <jtv@xs4all.nl>)
Ответы Re: Avoiding bad prepared-statement plans.  (Mark Mielke <mark@mark.mielke.cc>)
Re: Avoiding bad prepared-statement plans.  (Dimitri Fontaine <dfontaine@hi-media.com>)
Список pgsql-hackers
Yeb Havinga wrote:

>> I've been discussing this with Josh, Heikki, and Peter E. over the 
>> past few weeks.
> Is this searchable in the archives? I'm interested in ideas discussed.

No, sorry.  These were face-to-face discussions at linux.conf.au and FOSDEM.


>> If a prepared statement takes parameters, and the generic plan has a 
>> high projected cost, re-plan each EXECUTE individually with all its 
>> parameter values bound.  It may or may not help, but unless the 
>> planner is vastly over-pessimistic, re-planning isn't going to 
>> dominate execution time for these cases anyway.

> This sounds like a really nice to have feature. Maybe it'd also be 
> possible to skip replanning between executes if the current bound values 
> are 'indexwise-equivalent' to the values used at previous planning, i.e. 
> nothing in the statistics indicates that execution cost would be (much) 
> different. Are there more ways to cut down on planning time? Obviously 
> some plannedstatement/plannerinfo structures could be kept, but maybe 
> it'd also be possible to plan only that part of the join tree where the 
> params are used in a scan/join qual.

I think we should be careful not to over-think this.  Planning isn't 
*that* costly, so apply Amdahl's Law liberally.  I'm proposing some easy 
things we could do without adding much overhead or maintenance burden; 
I've been assuming that getting intimate with the planner would risk 
those advantages.


Jeroen


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

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: TCP keepalive support for libpq
Следующее
От: Richard Huxton
Дата:
Сообщение: Re: Avoiding bad prepared-statement plans.