maria-developers team mailing list archive

[MARK CALLAGHAN <mdcallag@xxxxxxxxx>]

Were I interested in writing a loosely coupled storage engine for
MySQL/MariaDB I like the API and docs available for PG and SQLite. We don't
have docs like that and the API was much more difficult back in the day
when I supported something that did this:
http://www.postgresql.org/docs/9.3/static/fdwhandler.html
http://www.postgresql.org/docs/9.3/static/fdw-callbacks.html
http://www.sqlite.org/vtab.html


On Fri, Sep 6, 2013 at 12:10 PM, Thomas Jones-Low <
thomas.jones-low@xxxxxxxxxxxxxxxx> wrote:

> 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.
>
>
>
> ______________________________**_________________
> Mailing list: https://launchpad.net/~maria-**developers<https://launchpad.net/~maria-developers>
> Post to     : maria-developers@lists.**launchpad.net<maria-developers@xxxxxxxxxxxxxxxxxxx>
> Unsubscribe : https://launchpad.net/~maria-**developers<https://launchpad.net/~maria-developers>
> More help   : https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp>
>



-- 
Mark Callaghan
mdcallag@xxxxxxxxx