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 jim@nasby.net
512.569.9461 (cell) http://jim.nasby.net
