Partitioning performance drops drastically with many partitions
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
MySQL Server |
Unknown
|
Unknown
|
||||
Percona Server moved to https://jira.percona.com/projects/PS | Status tracked in 5.7 | |||||
5.1 |
Won't Fix
|
Low
|
Unassigned | |||
5.5 |
Triaged
|
Low
|
Unassigned | |||
5.6 |
Fix Released
|
Low
|
Unassigned | |||
5.7 |
Invalid
|
Low
|
Unassigned |
Bug Description
This has been documented and apparently fixed in this upstream bug in MySQL 5.6:
http://
Basically, more partitions == much worse performance. I just used the example script from that bug to verify the behaviour on a fresh install of Percona Server 5.5.25a-27.1-log. I changed the script to use 100000 rows because 10000 rows completed too quickly on my hardware, and got the following results:
INSERT Engine: MyISAM, partitioning YES, time 42.2766079902649.
INSERT Engine: MyISAM, partitioning NO, time 8.36221385002136.
INSERT Engine: Innodb, partitioning YES, time 46.502082824707.
INSERT Engine: Innodb, partitioning NO, time 12.8495020866394.
INSERT Engine: Falcon, partitioning YES, time 32.1179881095886.
INSERT Engine: Falcon, partitioning NO, time 12.4245889186859.
We're starting to use larger partition counts pretty heavily, so we'd definitely like to see the fix backported to Percona Server 5.5 and 5.1 if possible.
tags: | added: upstream |
Tested on PS 5.5.27-28.1
./bug37252.pl
INSERT Engine: MyISAM, partitioning YES, time 7.48948097229004.
INSERT Engine: MyISAM, partitioning NO, time 5.67519211769104.
INSERT Engine: Innodb, partitioning YES, time 13.065337896347.
INSERT Engine: Innodb, partitioning NO, time 7.52108716964722.
INSERT Engine: Falcon, partitioning YES, time 13.8746740818024.
INSERT Engine: Falcon, partitioning NO, time 7.78384900093079.
(Don't consider absolute numbers (since I ran it in a VM), just the percentage decrease - looks to be around 30 - 50%)
my.cnf used - http:// sprunge. us/BWcI