| From: | Jeroen Vermeulen <jtv(at)xs4all(dot)nl> |
|---|---|
| To: | Yeb Havinga <yebhavinga(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Avoiding bad prepared-statement plans. |
| Date: | 2010-02-09 13:46:55 |
| Message-ID: | 4B71674F.6030505@xs4all.nl |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Richard Huxton | 2010-02-09 13:50:32 | Re: Avoiding bad prepared-statement plans. |
| Previous Message | Magnus Hagander | 2010-02-09 13:45:01 | Re: TCP keepalive support for libpq |