* Brian Aker <brian@stripped> [09/05/22 21:05]:
> The theory is that there is a lot of copying going on in the server and
> that a value object might solve some of this. It would also keep for a
> nice bit of abstraction around data held by engines.
> The current system is very optimized for MyISAM/HEAP, and there may, or
> may not, be some gain in removing that to make the interface more
> optimum for other engines. See the earlier thread about the contents of
> row and the unireg in memory format.
Value class doesn't require MyISAM/HEAP to change
its record format, on disk or in memory. It's just that the server
won't ever have to know what this format is -- it will talk to
MyISAM by means of get() and store(), calling them only when
As to the amount of copying, I believe in future we will be able
to actually reduce it: having a single class responsible to carry
a value, independent of the parse tree, will allow us to use one
of the register allocation algorithms to minimize the amount of
independent values necessary to evaluate an expression.
> Keep in mind that in all of the current trees MyISAM/HEAP are used as
> internal temp tables and that any change could easily result in poor
> performance in the core.
Hard to discuss whether we can break it or not without having an
architecture specification at hand. There is always a possibility
of breaking something.