>> Ofcourse, this is another can of worms. To do this you would have to be
>> able to have the failed query provide hints to the planner telling it
>> where it went wrong. Now, it may be possible to provide (via
>> post-mortem of an execution) a list of actual selectivites like:
>
> Just being able
> Ofcourse, this is another can of worms. To do this you would have to be
> able to have the failed query provide hints to the planner telling it
> where it went wrong. Now, it may be possible to provide (via
> post-mortem of an execution) a list of actual selectivites like:
Just being able to pro
On Tue, Dec 13, 2005 at 12:44:50PM +0800, Christopher Kings-Lynne wrote:
> And the answer is interesting as well:
>
> "I think we have to approach it in two ways. One is that you have to be
> able to execute good plans, and during the execution of a plan you want
> to notice when the actual data
Chris,
On 12/12/05 8:44 PM, "Christopher Kings-Lynne" <[EMAIL PROTECTED]>
wrote:
> assumption of five. Thus, being able to correct mid-course is an area of
> enhancement for query optimizers that IBM is pursuing."
>
> Hmmm dynamic re-planning!
I recently interviewed someone who is in the resear
I saw it in print; the only thing that seemed interesting about it was
the recommendation that query optimization be biased towards the
notion of "stable plans," query plans that may not be the most
"aggressively fast," but which don't fall apart into hideous
performance if the estimates are a lit
> http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=297
I saw it in print; the only thing that seemed interesting about it was
the recommendation that query optimization be biased towards the
notion of "stable plans," query plans that may not be the most
"aggressively fast," but whi
