| Thread Previous • Date Previous • Date Next • Thread Next |
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.
| Thread Previous • Date Previous • Date Next • Thread Next |
