Igor Babaev wrote: > On 04/12/2013 09:00 AM, Axel Schwenke wrote: >> Hi Igor, Timour, >> >> when I wrote the script to translate MariaDB table statistics to MySQL, >> I found one problem. Imagine this simple table: >> >> create table t1 (c1 int, c2 int, c3 int, >> primary key (c1, c2), >> index `secondary`(c3)); >> >> Here the secondary index has 3 parts, it can be used as (c3), (c3, c1) >> and (c3, c1, c2). Obviously the avg_frequency is 1 for (c3, c1, c2), but >> it is not obvious how it is for (c3, c1). Such data I'd expect to see in >> the index_stats table under prefix_arity=2, but it's not there. > > To get this you have to run analyze with > set optimizer_switch='extended_keys=on';
Thanks Igor, this is a piece I was missing. While I see the point to obey the extended_keys optimizer switch in ANALYZE TABLE, I wonder if this is a good idea. The optimizer switch is dynamic, so a user can change it, even for a single query. But when the statistics for the extended key is not available, this makes not much sense. I suggest to always collect extended keys statistics, regardless of the setting of the extended_keys optimizer switch. Rationale: it is easy to simply not use the data when extended_keys=off. The only counter argument would be that this is costly - but I cannot see this. XL _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
