Aria engine horrible performance TRANSACTIONAL=1

Hi Guys,

im having issue with aria engine, ONLY when using TRANSACTIONAL=1, which is unfortunately the default setting it seems. Basically IO subsystem on the server gets exhausted completely and queries like

SELECT * FROM "raw_stats_other" LIMIT 1 take eg. 200-600 seconds to return a row that has 30 bytes of data. Traffic is almost write-only with 5-10 concurrent writes at a time, with occassional reads. Each single write consist of "packed" write to 100 rows with ON DUPLICATE KEY UPDATE.

The difference is so huge that when i switched the table to TRANSACTIONAL=0, the server behaved like there's no traffic at all.
SELECT * FROM "raw_stats_other" LIMIT 1 time dropped from 200-600 seconds to just <0.05s.

The problem isn't really the very bad performance, but lack of documentation. There should be some info about flushing strategy, and how TRANSACTIONAL=1 affects the IO (i don't know maybe that's how it's supposed to work as it's flushing every write to disk?). And most important, if there's a way of improving it or not. Is it not suitable for conventional HDD's and high write enviroments at all?

While i have not much experience with mariadb and considering lack of documentation i thought at first that... the engine is just broken which is a shame, because when properly configured it works very nicely... where there's not a single line of info of how badly transactional options i affecting write performance and how it really works.

I marked this issue as critical, because i think many people would drop the DB altogether thinking it's broken because lack of information.

CREATE TABLE `raw_stats_other` (

  `raw_stats_lookup_id` int(11) NOT NULL,

  `attrib_id` smallint(6) NOT NULL,

  `date` date NOT NULL,

  `raw_stats_value_id` int(255) NOT NULL,

  `impressions` int(11) NOT NULL,

  `_cf` int(11) NOT NULL,

  UNIQUE KEY `tag_stats_lookup_id` (`date`,`raw_stats_lookup_id`,`attrib_id`,`raw_stats_value_id`) USING BTREE

) ENGINE=Aria DEFAULT CHARSET=utf8 TRANSACTIONAL=1

/*!50100 PARTITION BY HASH (TO_DAYS(date) DIV 10)

PARTITIONS 5 */;