Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ps 5.7 db 925 #345

Merged
merged 2 commits into from Feb 8, 2016
Merged

Ps 5.7 db 925 #345

merged 2 commits into from Feb 8, 2016

Conversation

george-lorch
Copy link
Contributor

George O. Lorch III added 2 commits February 3, 2016 12:17
…ate after the changes introduced by DB-848

* Issue is due to a bad optimization added during the cardinality rework from https://blueprints.launchpad.net/percona-server/+spec/tokudb-background-auto-analyze
* This only happenes with partitioned tables. There were cases where the optimizer and/or partition handler would call the handler to update the shared key record count structures multiple times and it would 'clear' the values in between calls. There was an optimization added in TokuDB that would not update the record count values if it knew that the cardinality had not changed since the last call, thus leaving all of the record counts in the 'cleared' state.
* Removed this optimization, re-recorded affected tests and validated the results against the same conditions in InnoDB.
* Removed 6 year old hack that was wrong in the first place to fix a '0' record count and replaced with logic matching InnoDB.
Conflicts:
	storage/tokudb/ha_tokudb.cc
	storage/tokudb/hatoku_cmp.cc
george-lorch pushed a commit that referenced this pull request Feb 8, 2016
@george-lorch george-lorch merged commit 0470a42 into percona:5.7 Feb 8, 2016
@george-lorch george-lorch deleted the ps-5.7-DB-925 branch February 8, 2016 18:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant