Re: [Maria-developers] Storage Engine API changes

[Kristian Nielsen]

[recipient list truncated to "internals@stripped"]

Peter Benjamin Volk <peter@stripped> writes:

> Multiple things. At first of course at column store oriented engines. The
> problem with this is that the MySQL core is strongly row based and would not
> take any column oriented optimizations into account even if the engine is
> column oriented. So any column store would actually need to bring their own
> optimizer and partially operators with them. The Idea would be to have a curser

It is not clear what optimizations you have in mind that would benefit column
oriented storage engines and which are not implemented currently. Maybe you
could elaborate?

> costs. For column oriented stores it would be cheaper to read over the column
> API and for row based it would read over the row API. To compensate the
> different APIs you can define different transformation operators. Also this way
> specific selections can be pushed down to the SE very easily--SELECT a,b FROM t
> would only read columns a and b from the table t. Instead of reading the
> complete row of t (maybe consisting of N+1 columns). The performance

This makes me think you are not fully aware of the column-orientated features
of the current storage engine API.

There should be no need for `SELECT a,b FROM t` to read other columns except
for a and b. Certainly NDB does not, and did not before the NDB record
interface either.

Eg. in the handler, the read_set can be used to know which columns (only) to
read from the engine.

Hope this helps,

 - Kristian.