<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><br class=""><blockquote type="cite" class="">12 марта 2018 г., в 19:47, Vladimir Davydov <<a href="mailto:vdavydov.dev@gmail.com" class="">vdavydov.dev@gmail.com</a>> написал(а):<br class=""><br class="">On Mon, Mar 12, 2018 at 07:16:31PM +0300, <a href="mailto:v.shpilevoy@tarantool.org" class="">v.shpilevoy@tarantool.org</a> wrote:<br class=""><blockquote type="cite" style="font-family: PTMono-Regular; 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;" class=""><br class=""><br class=""><blockquote type="cite" class="">12 марта 2018 г., в 19:10, Vladimir Davydov <vdavydov.dev@gmail.com> написал(а):<br class=""><br class="">On Mon, Mar 12, 2018 at 05:41:12PM +0300, v.shpilevoy@tarantool.org wrote:<br class=""><blockquote type="cite" class=""><br class=""><br class=""><blockquote type="cite" class="">12 марта 2018 г., в 16:03, Vladimir Davydov <vdavydov.dev@gmail.com> написал(а):<br class=""><br class="">On Mon, Mar 12, 2018 at 12:53:36AM +0300, Vladislav Shpilevoy wrote:<br class=""><blockquote type="cite" class="">Vinyl alter can change comparators, for example, by removal of a<br class="">space format and making some fields optional. This alter is<br class="">allowed on a non-empty space even, because optionality of a<br class="">field is not persisted. But index key definitions can not be<br class="">updated in place, since they are used in multiple threads (vinyl<br class="">workers). So it is necessary to get new key definitions from a<br class="">new index definition, and leave old ones to be deleted by<br class="">existing worker tasks, when they will be finished.<br class=""></blockquote><br class="">I don't think that workers alone are worth introducing key_def reference<br class="">counting - we can just copy key_def for them, it is a slow path after<br class="">all.<br class=""></blockquote><br class="">We can, but further we want to store key_def per mem and per run to<br class="">allow various formats and keys in different places.<br class=""></blockquote><br class="">But why? All tuples stored in an index should have the same format and<br class="">be compared by the same key definition, no?<br class=""></blockquote><br class="">Now yes. Later - no. On vinyl alter you can not update formats in all older tuples in all mems and runs.<br class=""></blockquote><br class="">I don't think I understand. If you change space format, all tuples must<br class="">conform to it, no? Why do we need a separate format per each run and/or<br class="">mem?<br class=""></blockquote><br class="">Exactly. But they may not be the same. They different, but compatible. I think, that the same can be applied to key_defs in a future. In a case of vinyl we must avoid full rebuild - it will be much and mush slower that memtx, and if key_def will be changed in a compatible way, then I do not see a reason to do not use it for rebuild avoidance.<br class=""><br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" style="font-family: PTMono-Regular; 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;" class="">And on index update you can not change key_defs too.<br class=""></blockquote><br class="">Why would you need to do anything like this? Just rebuild the whole<br class="">index on key_def alter, that's all. Simple and robust.<br class=""></blockquote><br class="">It is not effective when a key_def is changed in a compatible way (for example, by extending of part types).<br class=""><br class=""><blockquote type="cite" class=""><br class="">To be honest, I find all those little tricks, like changing key field<br class="">type from unsigned to signed without rebuild, useless. Anybody needs<br class="">that?<br class=""></blockquote><br class="">You think, that it useless, but lets see how many time rebuild consumes on a space with, for instance, 5 000 000 000 tuples?<br class=""><br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" style="font-family: PTMono-Regular; 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;" class=""><br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class="">sk = s:create_index('sk', {parts = {{2, 'unsigned', is_nullable = true}}})<br class="">s:format({}) -- this will fail, because min_field_count is changed. But user even does not know about 'min_field_count'. We simply can not explain to a user, why it is forbidden.<br class=""></blockquote><br class="">Who cares? De facto, vinyl doesn't support alter at all. The user can<br class="">drop all indexes and recreate the space with another format.<br class=""></blockquote><br class="">Vinyl supports alter. At least, it allows to update format in compatible ways.<br class=""></blockquote><br class="">You've recently forbidden altering key_def of an empty vinyl index, and<br class="">nobody cared. How's space format any different?<br class=""></blockquote><br class="">I have forbidden key definition alter, yes, but I did not forbid to create/drop an index. And these hacks are only for empty spaces. On a non-empty space key_definition has no worked ever.<br class="">Now you propose to forbid alteration of a non-empty space. And for a reason, that can not be even explained to a user. With the same success we can forbid any alter of Vinyl spaces, except disk options (page sizes etc).<br class=""><br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" style="font-family: PTMono-Regular; 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;" class=""><br class=""><blockquote type="cite" class=""><br class="">Anyway, the fact that you can't change a key definition or space format<br class="">without potentially affecting other key definitions looks cheesy...<br class=""></blockquote><br class="">A user does not see changes of non-altered indexes. So it is not cheesy.<br class=""></blockquote><br class="">I didn't mean users, I meant the ALTER code - it's getting more and more<br class="">convoluted. And the bug you're fixing is a living proof to that.<br class=""></blockquote><br class="">It always was slightly "convoluted". Somewhere it complicates, and somewhere it simplifies - the ModifySpaceFormat is "living proof to that" - it removed many of doubtful code from ModifySpace.<br class=""><br class=""><br class=""></body></html>