From: Kirill Shcherbatov <kshcherbatov@tarantool.org> To: tarantool-patches@freelists.org, Vladislav Shpilevoy <v.shpilevoy@tarantool.org> Subject: [tarantool-patches] Re: [PATCH v1 2/5] box: introduce slot_cache in key_part Date: Wed, 15 Aug 2018 15:14:47 +0300 [thread overview] Message-ID: <c58b635a-a384-24ce-ff4a-e552d5bbca63@tarantool.org> (raw) In-Reply-To: <ef2cf1f5-b439-34c3-49a3-a004f4079922@tarantool.org> >> - const struct key_part *part = key_def->parts; >> + struct key_part *part = (struct key_part *)key_def->parts; > 1. Why? Fixed. > 2. These things were needed to get formats and tuples data once. Now you > lookup format and raw data on each part in the cycle below. So it is > slower in part_count times. See below the main comment. > 3. As I said you verbally, when we were discussing how to implement > comparators, you do not need to use slot cache, epochs and other > complex JSON things to compare flat index keys, with no JSON paths. You > should add a new template parameter to tuple_compare_slowpath like > 'is_flat' or something, and if it is false, then use regular tuple_field > or tuple_field_raw. If true, then try to use slot cache, epoch etc. > Comparators are chosen once when key_def is created and template 'if' > is compile time, so these 'if's will cost nothing. > > Now tuple_field_by_part is much slower than tuple_field_raw - it makes > additional lookup of a format (from a huge array of tuple formats), > of tuple data (additional call), field map (one more call). Further > both tuple_field_by_part and tuple_field_raw do 3 'if's and lookup > in field_map. But tuple_field_raw also updates slot_cache and > format_epoch - it is +2 assignments. So tuple_field_raw is faster. > In this cycle in the summary it is in part_count times faster. > > So please, do not use tuple_field_by_part for flat indexes. It has no > profit for them. > > All the same about key extraction and hash. Done as you've suggested. > 4. Tuple format should not depend on tuple. Vice versa. Please, > consult other tuple_field methods how to solve this dependency > cycle. There is no such problem already. > 5. Looks like you've ignored my point that a global format > epoch will expire epoch in all formats when just a one > space is altered. Please, do not. Epoch should be one per > space. I've introduced new function space_format_update_epoch that is called on alter. > 6. Prefix flags with 'is_'. Ok, fixed. > 7. Why do you need it? I've reeworked this function a lot as a part of following patch. Here is wrapper that calls tuple_field_raw now in this patch. > 8. Too small comment for such complex feature. I've wrote a bigger comment.
next prev parent reply other threads:[~2018-08-15 12:14 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-08-06 12:26 [tarantool-patches] [PATCH v1 0/5] box: indexes by JSON path Kirill Shcherbatov 2018-08-06 12:26 ` [tarantool-patches] [PATCH v1 1/5] rfc: describe a Tarantool JSON indexes Kirill Shcherbatov 2018-08-06 12:26 ` [tarantool-patches] [PATCH v1 2/5] box: introduce slot_cache in key_part Kirill Shcherbatov 2018-08-08 22:03 ` [tarantool-patches] " Vladislav Shpilevoy 2018-08-15 12:14 ` Kirill Shcherbatov [this message] 2018-08-06 12:27 ` [tarantool-patches] [PATCH v1 3/5] box: introduce path field " Kirill Shcherbatov 2018-08-08 22:03 ` [tarantool-patches] " Vladislav Shpilevoy 2018-08-15 12:14 ` Kirill Shcherbatov 2018-08-06 12:27 ` [tarantool-patches] [PATCH v1 4/5] box: introduce path_hash and tuple_field tree Kirill Shcherbatov 2018-08-08 22:03 ` [tarantool-patches] " Vladislav Shpilevoy 2018-08-15 12:14 ` Kirill Shcherbatov 2018-08-06 12:27 ` [tarantool-patches] [PATCH v1 5/5] box: specify indexes in user-friendly form Kirill Shcherbatov 2018-08-08 22:03 ` [tarantool-patches] Re: [PATCH v1 0/5] box: indexes by JSON path Vladislav Shpilevoy 2018-08-15 12:14 ` Kirill Shcherbatov
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=c58b635a-a384-24ce-ff4a-e552d5bbca63@tarantool.org \ --to=kshcherbatov@tarantool.org \ --cc=tarantool-patches@freelists.org \ --cc=v.shpilevoy@tarantool.org \ --subject='[tarantool-patches] Re: [PATCH v1 2/5] box: introduce slot_cache in key_part' \ /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