<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 12 Nov 2018, at 02:22, Vladislav Shpilevoy <<a href="mailto:v.shpilevoy@tarantool.org" class="">v.shpilevoy@tarantool.org</a>> wrote:</div><div class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">On 12/11/2018 02:16, n.pettik wrote:</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><blockquote type="cite" class="">On 9 Nov 2018, at 12:25, Vladislav Shpilevoy <<a href="mailto:v.shpilevoy@tarantool.org" class="">v.shpilevoy@tarantool.org</a> <<a href="mailto:v.shpilevoy@tarantool.org" class="">mailto:v.shpilevoy@tarantool.org</a>>> wrote:<br class=""><br class="">Hi! Thanks for the patch! I understand, that Vova said<br class="">that it should not be pushed, but Kirill asked me, on<br class="">the contrary, to review it. So I do.<br class=""></blockquote>Vladimir didn’t suggest better solutions except for complete reworking<br class="">them. Now it is definitely bug which leads to wrong results of<br class="">SELECT queries (which is a terrible thing taking into account the fact that<br class="">SQL is supposed to be used mostly for DQL). So lets take this patch as<br class="">a workaround and rework ephemeral tables when we will have enough time<br class="">and resources (surely if Kirill and Vladimir don’t mind).<br class="">With this bug it seems to be unacceptable to release beta version.<br class=""><blockquote type="cite" class="">On 29/10/2018 22:02, Nikita Pettik wrote:<br class=""><blockquote type="cite" class="">Ephemeral space are extensively used in SQL to store intermediate<br class="">results of query processing. To keep things simple, they feature only<br class="">one unique index (primary) which covers all fields. However, ephemeral<br class="">space can be used to store non-unique entries. In this case, one<br class="">additional field added to the end if stored data:<br class="">[field1, ... fieldn, rowid]<br class="">Note that it can't be added to the beginning of tuple since data in<br class="">ephemeral space may be kept as sorted. Previously, to generate proper<br class="">rowid index_max() was used. However, it is obviously wrong way to do it.<br class="">Hence, lets add simple integer counter to memtx space (ephemeral spaces<br class="">are valid only for memtx engine) and introduce method in vtab to fetch<br class="">next rowid value.<br class="">Needed for #3297<br class="">---<br class=""> src/box/blackhole.c | 1 +<br class=""> src/box/errcode.h | 2 ++<br class=""> src/box/memtx_space.c | 17 +++++++++++++++++<br class=""> src/box/memtx_space.h | 7 +++++++<br class=""> src/box/space.c | 9 +++++++++<br class=""> src/box/space.h | 3 +++<br class=""> src/box/sysview.c | 1 +<br class=""> src/box/vinyl.c | 1 +<br class=""> src/errinj.h | 1 +<br class=""> test/box/errinj.result | 2 ++<br class=""> test/box/misc.result | 1 +<br class=""> 11 files changed, 45 insertions(+)<br class="">index 04f4f34ee..fab8b6617 100644<br class="">--- a/src/box/errcode.h<br class="">+++ b/src/box/errcode.h<br class="">@@ -223,6 +223,8 @@ struct errcode_record {<br class="">/*168 */_(ER_DROP_FK_CONSTRAINT,"Failed to drop foreign key constraint '%s': %s") \<br class="">/*169 */_(ER_NO_SUCH_CONSTRAINT,"Constraint %s does not exist") \<br class="">/*170 */_(ER_CONSTRAINT_EXISTS,"Constraint %s already exists") \<br class="">+/*171 */_(ER_ROWID_OVERFLOW,"Rowid is overflowed: too many entries in ephemeral space") \<br class="">+<br class=""></blockquote><br class="">This error message as well as check on uint64_max are<br class="">not necessary, IMHO. I can not imagine how many hundreds of<br class="">years a one should insert into one ephemeral table to<br class="">reach this limit.<br class=""></blockquote>It is true that 2^64 is likely to be quite huge number of tuples,<br class="">but for instance JOIN uses nested-loop algorithm, so it requires<br class="">n^2 memory for ephemeral table to comprise results.<br class="">In this regard, to reach the limit we need 4-way join where each<br class="">table contains 2^16 entries, which in turn doesn’t seem to be giant.<br class="">*It is only thoughts tho, I haven’t tested it since I suppose very likely<br class=""> my pc would simply get stuck.*<br class="">I wanted to create long test as the easiest solution, but Alexander warned<br class="">me that Travis may not survive such test due to lack of memory.<br class=""></blockquote><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">I do not mind, if you drop my fixes. It is just nitpicking. The</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">patchset is generally ok already.</span></div></blockquote><br class=""></div><div>Actually, I don’t mind your fixes as well, so I am going to apply them.</div><div>Also, I’ve rebased patch-set on fresh 2.1.</div><br class=""></body></html>