Comments - Aria System Variables: aria_block_size

8 years, 1 month ago Paul Pech

When reducing aria_block_size the maximum index key length is being reduced as well. It seems that aria_block_sizes greater than or equal to 4096 allow for a maximum key length of 1000 bytes (this is the maximum key length for the default myisam_block_size of 1024), while for aria_block_size 2048 max. key length is 552 bytes (for 1024 it's 210).

In our tests reducing aria_block_size from 8192 (default) to 4096 did only lead to a minor performance improvement. I'll try to reduce to 2048, but I'll have to adapt some indexes first :-)

When using aria_block_size 4096 performance still is reduced by more than 30% compared to MyISAM (same server, same databases, same indexes; many full table scans). Is this to be expected or must there be something I'm doing wrong? (Server is 10.0.22, openSuSE Leap 42.1 default package)

 
8 years, 1 month ago Ian Gilfillan

For full table scans, the default PAGE format is slower than the DYNAMIC and FIXED formats. Perhaps this explains the difference in your case. See the Aria FAQ.

 
8 years, 1 month ago Paul Pech

I tried reducing aria_block_size to 2048 but performance improvements were negligible. So I guess that using PAGE format, as Ian said, explains the very noticeable drop in performance compared to MyISAM.

Just for the fun of it, I'll give it a try with DYNAMIC format, but that does mean that the tables won't be crash free.

I read that Aria 2.5 will focus on performance improvements. Any chance that full tables scans will be addressed, if that's even possible?

 
8 years, 1 month ago Ian Gilfillan

Yes, only PAGE format tables (with TRANSACTIONAL=1, which is not the default) are crash safe. There's not much activity with Aria development at the moment, so I'm not sure when full scan performance will be looked at.

 
Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.