Comment 4 for bug 1538765
Revision history for this message
| George Ormond Lorch III (gl-az) wrote | #4 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
Correct Sveta, this is exactly how InnoDB (and TokuDB) stats work. Generally the rec_per_key is 'static' in that it only gets counted and stored during an ANALYZE TABLE (or auto analyze). The optimizer/SQL layer then uses this static rec_per_key data set that it gets from the ::info call with a 'dynamic' or constantly changing row count estimate, thus giving the appearance that the resulting cardinality calculation is changing when it is the row count that is changing. This is why inaccurate row counts (a nagging TokuDB issue) can cause cardinality calculation errors and thus sub-optimal index choices.