On 24.02.2011 12:59, Jonas Oreland wrote:
> On 02/24/11 12:21, Ole John Aske wrote:
>> On 23.02.2011 19:15, Jonas Oreland wrote:
>>> On 02/23/11 19:07, Ole John Aske wrote:
>>>> On 23.02.2011 18:00, Jonas Oreland wrote:
>>>>> Hi OJ,
>>>>>
>>>>> 1) What do you think about using heuristic even if we don't have
> row-count.
>>>>> E.g if we don't have row-count, set it to 100 and run you
> range-heuristic anyway
>>>> Yes, would likely be usefull in those cases.
>>> can you produce a deterministic testcase for this too...i'd be happy...
>>> but i'm also ok with skipping if it's hard
>> I got some second thoughts here:
>>
>> There are several handler methods which currently trap the 'don't have
> row-count'
>> state. From top of my head ::records_in_range, ::info() and ::scan_time() might
> be some
>> of them.
>>
>> Currently 'don't have row-count' is handled by assuming 2 rows.
>>
>> - Changing this to assume 100 rows for ::records_in_range() only
>> will likely cause situations where a full table scan is preferred
>> over a range which will be a performance regression.
>>
>> - Changing 'unknown' to be 100 rows in all places where this is trapped
>> is likely to create lots of changed query plans and EXPLAIN's in MTR tests.
>> ... I don't think we want this either.....
>>
>> So my suggestion is to don't change this and instead wait for my
>> 'persistent statistics' patch which will hopefully remove all of these
>> 'unknown row-count' situations.
> i think changing unknown from 2 to 100...sound ok...even good (at all locations of
> unknown)
> and can't think of any scenario in which this would result in a poorer query plan
> than what one
> can get with 2...can you ?
I can test this and report back later
Ole John
> /Jonas
