maria-developers team mailing list archive
Mailing list archive
Re: Can there be a better storage engine API?
On 8/13/13 6:41 PM, MARK CALLAGHAN wrote:
Do we need a better API or is the current code good enough? I hope to
hear from people who have done serious storage engine work.
I'm another person who did a storage engine implementation for MySQL.
The Akiban adapter for MySQL did make it to GA, but was not widely adopted.
Our frustrations with the existing API were it's inconsistencies.
Specific aggravations were:
- The Create Table data didn't include the anything not supported by
the MyISAM engine. Which meant digging through the Lex structure to find
Foreign Keys declarations. This added a whole layer of complexity to the
create and alter table processing.
- Data type access. As part of our engine, we ended up translating the
MySQL data and Datatypes to our own internal one. But the interface on
the types was so inconsistent, we couldn't make one call to the type to
extract/insert the data for each type.
- No Access to the Optimizer. The Akiban engine was doing some
interesting things with data layout to improve join performance. We had
no way of hinting to the Optimizer to prefer x,y join over y,z join.
- In addition to the begin/end transaction, we were looking for begin
and end of a statement. We were doing this because the data for, what
looked to MySQL as multiple tables, query may be loaded in one large
chunk. Access to the list of tables used in a single query was not
available easily, and the definitive start and end processing of a query
to know when to stop our processing.
- Returning errors is inconsistent and dependent upon the MyISAM engine
assumptions of what could and could not error. So we would have problems
notifying the user that their query had failed
Many of the other oddities and badness we also encountered and found a
work around for.