On Fri, Sep 01, 2006 at 11:53:11AM +0200, Martijn van Oosterhout wrote: > On Fri, Sep 01, 2006 at 03:56:19PM +0700, Jeroen T. Vermeulen wrote: > > That's a very common thing in processor design as well, and there's a > > standard trick for it: the saturating two-bit counter. It tends to work > > pretty well for branch prediction, value prediction etc. Usually it's the > > first thing you reach for, so of course somebody may already have tried it > > here and found it didn't work. > 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.
The difference between a pre-planned query, and a plan each time query, for me, seems to be a minimum of around 0.3 - 0.5 ms. This is on a fairly modern AMD X2 3800+. If the tests and counting are kept simple - I don't see why they would take anywhere near that long. Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match