[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