List:Internals« Previous MessageNext Message »
From:Sergey Vojtovich Date:December 20 2010 11:34am
Subject:Re: On-line cardinality for MEMORY tables
View as plain text  
Hi Maxim,

thanks for this great patch! It looks good overall, but there
are a few things that need to be addressed before we can
incorporate it into our source trees.

1. There are tab characters in keys_compare(), please replace
   with spaces. See also:

2. It would be great if this feature is covered by tests. See also:

3. The values you're using in scan_time() and read_time() seem to
   be correct, but I want to double check with the optimizer team.

4. Since this feature has 5-10% overhead on delete, probably it is
   a good idea let users turn it off when needed. It can be achieved
   by adding new system variable. See also:
   ...or other storage engines that expose system variables.


On Mon, Nov 08, 2010 at 01:47:12AM +0300, Maxim Deviatov wrote:
> Hi there,
> a few years ago I was playing with B-tree index cardinality
> of MEMORY storage engine and come up with a patch (attached)
> implementing on-line cardinality calculation.
> According to my benchmarks, in certain cases MEMORY table scan
> may be up to 45% faster than index scan. But since MEMORY engine
> doesn't provide cardinality for B-tree indexes, index scan is
> always preferred over table scan.
> The idea of the patch is to provide accurate cardinality for
> B-tree indexes at any time.
> Max overhead should be 5-10% slowdown of DELETE/UPDATE queries.
> Have fun,
> =====================
> Maxim N. Deviatov

> -- 
> MySQL Internals Mailing List
> For list archives:
> To unsubscribe:

Sergey Vojtovich <svoj@stripped>
MySQL AB, Software Engineer
Izhevsk, Russia,
On-line cardinality for MEMORY tablesMaxim Deviatov7 Nov
  • Re: On-line cardinality for MEMORY tablesLenz Grimmer22 Nov
    • Re: On-line cardinality for MEMORY tablesSergey Vojtovich26 Nov
  • Re: On-line cardinality for MEMORY tablesSergey Vojtovich20 Dec