[MDEV-9615] PerconaFT FT-684 estimated # of rows in a table could become inaccurate after deletes Created: 2016-02-23  Updated: 2016-06-22  Resolved: 2016-06-22

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - TokuDB
Affects Version/s: 10.1.11
Fix Version/s: 10.0.26, 10.1.15

Type: Bug Priority: Critical
Reporter: Reinis Rozitis Assignee: Sergei Golubchik
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
PartOf
is part of MDEV-10224 10.0.26 merge Closed
Sprint: 10.0.26

 Description   

After checking https://tokutek.atlassian.net/browse/FT-684 I saw that the issue has been fixed in https://github.com/percona/PerconaFT/pull/333 on Nov 15 2015 (merged also into master) but the source in https://github.com/MariaDB/server/tree/10.1/storage/tokudb/PerconaFT doesn't seem to include this patch.

Any ETA or roadblocks to merge this also in Maria tree?

The wrong row count estimate sometimes makes the optimiser to choose very bad query plans.

 Comments   
Comment by Sergei Golubchik [ 2016-02-23 ]

Unfortunately, ETA — no, roadblocks — yes.

Since MariaDB 10.0.23 we have TokuDB 5.6.26-74.0. The latest one is 5.6.28-76.1.
I have merged 5.6.27-76.0 and then 5.6.28-76.1. Unfortunately, they weren't usable, the first one didn't even compile, the latest compiled fine, but then crashed in tests. This is bug lp:1546538 — note that it has high importance, so hopefully it will be fixed soon.

Percona is doing quite a lot of changes in TokuDB, bugs are understandable. And they fix them fast, but still so far there was no TokuDB release since 5.6.26-74.0 that we can use.

Comment by Reinis Rozitis [ 2016-02-23 ]

Ok, thanks for the clarification.
Lets hope Percona addresses the memory allocation in timely fashion.

Comment by Reinis Rozitis [ 2016-05-09 ]

Seems that the upstream has as fix now: https://tokutek.atlassian.net/browse/DB-962

Generated at Thu Feb 08 07:36:01 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.