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.
Re: Avoiding bad prepared-statement plans. |
| Список | 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 по дате отправления: