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 ?
/Jonas
