On Fri, Sep 01, 2006 at 04:14:32PM +0100, Gregory Stark wrote:
> >> Interesting thought. It might be worth trying. But my big question: is
> >> all this testing and counting actually going to be faster than just
> >> replanning? Postgresql's planner is not that slow.
> >
> > In the best case (which of course would have to be very frequent for any
> > of this to matter in the first place) it's mainly just a short loop
> > comparing the call's parameter values to their counterparts stored with
> > the plan and update those two-bit confidence counters.  You wouldn't
> > *believe* how simple you have to keep these things in processor
> > architecture.  :-)
> I think the slow part is trying to figure out whether to count the current
> call as a hit or a miss. How do you determine whether the plan you're running
> is the best plan without replanning the query?

Simply looking at estimated row counts/cost versus what actually
happened would probably suffice. It'd at least be a great start.
Jim C. Nasby, Database Architect                   [EMAIL PROTECTED]
512.569.9461 (cell)                         http://jim.nasby.net

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?


Reply via email to