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? http://archives.postgresql.org
