Hi Robert,<br /><br /><div class="gmail_quote">On Tue, Feb 9, 2010 at 17:43, Robert Haas <span dir="ltr"><<a
href="mailto:robertmhaas@gmail.com">robertmhaas@gmail.com</a>></span>wrote:<br /><blockquote class="gmail_quote"
style="margin:0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">On Tue,
Feb9, 2010 at 7:08 AM, Jeroen Vermeulen <<a href="mailto:jtv@xs4all.nl">jtv@xs4all.nl</a>> wrote:<br /> > =
Projected-costthreshold =<br /> ><br /> > If a prepared statement takes parameters, and the generic plan has a
high<br/> > projected cost, re-plan each EXECUTE individually with all its parameter<br /> > values bound. It
mayor may not help, but unless the planner is vastly<br /> > over-pessimistic, re-planning isn't going to dominate
executiontime for<br /> > these cases anyway.<br /><br /></div>How high is high?<br /></blockquote></div><br
/>Perhapsthis could be based on a (configurable?) ratio of observed planning time and projected execution time. I mean,
ifplanning it the first time took 30 ms and projected execution time is 1 ms, then by all means NEVER re-plan. But if
planningthe first time took 1 ms and resulted in a projected execution time of 50 ms, then it's relatively cheap to
re-planevery time (cost increase per execution is 1/50 = 2%), and the potential gains are much greater (taking a chunk
outof 50 ms adds up quickly).<br /><br />Cheers,<br />Bart<br />