From: Chris Sosnin <k.sosnin@tarantool.org> To: Vladislav Shpilevoy <v.shpilevoy@tarantool.org> Cc: tarantool-patches@dev.tarantool.org Subject: Re: [Tarantool-patches] [PATCH v2] box: add binary search for _session_settings space Date: Sat, 25 Jan 2020 10:04:55 +0300 [thread overview] Message-ID: <B7B9954B-54F4-4F3D-95EC-191724C0D6D3@tarantool.org> (raw) In-Reply-To: <77348412-c9ac-54e7-2997-f9b2a2a9e0cb@tarantool.org> [-- Attachment #1: Type: text/plain, Size: 1887 bytes --] Hi! Thank you for the review and your fixes! See my answers below. > 3. I would rather say to '*an* existing'. Because there is no a one > certain setting to which all the iterators point after setting that > flag. Thank you, I agree. > 4. Even though that bsearch passes the tests, I failed to understand > it. Please, consider a more canonical bsearch on the branch in a > separate commit. Feel free to comment, if someone catches your attention > in my version and you don't agree. Your version is better, I agree, my code just implements lower/upper bound, but there is no point in it, because all settings are unique. Thanks! >> + if (low < count) { >> + int cmp = strcmp(name[low], key); >> + if ((cmp == 0 && is_including) || >> + (cmp > 0 && !is_eq)) { >> + *sid = low; >> + return 0; >> + } >> + } > > 5. This last strcmp can be avoided. Or at least > moved into the cycle. See my commit. > > All the same about 'reverse' version. I believe with your fixes it doesn’t really matter anymore. > > 6. What I don't like here is that we check is_set as many times, > as many modules we have. Moreover, if set_forward didn't find > anything, you fallback to a fullscan in that module, even though > it wont find anything with 100% guarantee. > > I fixed it, see my commit. The thing is that if set_forward fails, then sid = count and next_in_module will immediately return -1. But if we are going to remove modules, then this part will be rewritten anyway. > I fixed settings tests also - there was no a check that > real settings space, and a user defined one return the same tuple count. It > could happen, that one of them returns 0 tuples, and it would be considered > success. > > Additionally, I added a test, which tries all existing iterators on every > setting. Thanks, I agree with those. [-- Attachment #2: Type: text/html, Size: 20312 bytes --]
prev parent reply other threads:[~2020-01-25 7:04 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-01-19 20:18 Chris Sosnin 2020-01-25 0:19 ` Vladislav Shpilevoy 2020-01-25 7:04 ` Chris Sosnin [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=B7B9954B-54F4-4F3D-95EC-191724C0D6D3@tarantool.org \ --to=k.sosnin@tarantool.org \ --cc=tarantool-patches@dev.tarantool.org \ --cc=v.shpilevoy@tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH v2] box: add binary search for _session_settings space' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox