<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class="">Are you sure that it is impossible to localize all insertions to the ephemeral tables and<br class="">allocate memory for them using malloc?</blockquote><br class=""></div><div class="">Without refactoring a lot of code — yes, it is barely possible.</div><div class="">Or at least, it would be very fragile containing several hacks.</div><div class="">As I have explained in the ticket (<a href="https://github.com/tarantool/tarantool/issues/3199" class="">https://github.com/tarantool/tarantool/issues/3199</a>),</div><div class="">I see two ways to point out to which table (ephemeral or not) given record is going to be inserted.</div><div class="">A) At compilation stage set flag to OP_MakeRecord which would indicate ephemeral status.</div><div class=""> However, this opcode doesn’t take cursor number as an argument. Thus, we must decide from</div><div class=""> context (at compilation time) to which table current record will be inserted. However, sometimes</div><div class=""> the same OP_MakeRecord is used to generate record to be inserted in ephemeral space</div><div class=""> as well as in ordinary one. </div><div class=""> I stick to the point that it is possible to divide code generation for these cases,</div><div class=""> but it would require a lot of refactoring.</div><div class=""><br class=""></div><div class="">B) Very frequently we have cursor number while adding OP_MakeRecord</div><div class=""> (since insertion almost always happens right after constructing record).</div><div class=""> Therefore, we can pass it OP_MakeRecord and there fetch its space id.</div><div class=""> (It will be enough since ephemeral spaces feature space id == 0).</div><div class=""> However, in practice we execute this opcode VERY frequently, so it has to</div><div class=""> be optimised as much as possible. On the other hand, moves described above</div><div class=""> would lead to performance issues.</div><br class=""><div class="">All points considered, I think chosen solution is still the best one.</div><div class=""><br class=""></div></body></html>