[patches] [PATCH] sql: release all region memory after VDBE's halt

n.pettik korablev at tarantool.org
Thu Mar 1 01:24:02 MSK 2018


> Are you sure that it is impossible to localize all insertions to the ephemeral tables and
> allocate memory for them using malloc?

Without refactoring a lot of code — yes, it is barely possible.
Or at least, it would be very fragile containing several hacks.
As I have explained in the ticket (https://github.com/tarantool/tarantool/issues/3199 <https://github.com/tarantool/tarantool/issues/3199>),
I see two ways to point out to which table (ephemeral or not) given record is going to be inserted.
A) At compilation stage set flag to OP_MakeRecord which would indicate ephemeral status.
    However, this opcode doesn’t take cursor number as an argument. Thus, we must decide from
    context  (at compilation time) to which table current record will be inserted. However, sometimes
    the same OP_MakeRecord is used to generate record to be inserted in ephemeral space
    as well as in ordinary one. 
    I stick to the point that it is possible to divide code generation for these cases,
    but it would require a lot of refactoring.

B) Very frequently we have cursor number while adding OP_MakeRecord
    (since insertion almost always happens right after constructing record).
    Therefore, we can pass it OP_MakeRecord and there fetch its space id.
    (It will be enough since ephemeral spaces feature space id == 0).
    However, in practice we execute this opcode VERY frequently, so it has to
    be optimised  as much as possible. On the other hand, moves described above
    would lead to performance issues.

All points considered, I think chosen solution is still the best one.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.tarantool.org/pipermail/tarantool-patches/attachments/20180301/0debb490/attachment.html>


More information about the Tarantool-patches mailing list