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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
