On Tue, Aug 22, 2006 at 11:56:17AM -0700, Mark Dilger wrote: > I proposed something like this quite a bit up-thread. I was hoping we > could have a mode in which the system would run the second, third, fourth, > ... best plans rather than just the best looking one, and then determine > from actual runtime statistics which was best. (The proposal also included > the ability to output the best plan and read that in at a later time in > lieu of a SQL query, but that part of it can be ignored if you like.) The > posting didn't generate much response, so I'm not sure what people thought > of it. The only major problem I see is getting the planner to keep track > of alternate plans. I don't know the internals of it very well, but I > think the genetic query optimizer doesn't have a concept of "runner-up #1", > "runner-up #2", etc., which it would need to have.
I think the biggest issue is that you'd have to account for varying load on the box. If we assume that the database is the only thing running on the box, we might be able to do that by looking at things like how much IO traffic we generated (though of course OS caching will screw with that). Actually, that's another issue... any plans run after the first one will show up as being artificially fast, since there will be a lot of extra cached data. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
