From: Konstantin Osipov <kostja@tarantool.org> To: tarantool-patches@freelists.org Cc: vdavydov.dev@gmail.com, Kirill Shcherbatov <kshcherbatov@tarantool.org> Subject: Re: [tarantool-patches] [PATCH v5 11/12] box: introduce offset slot cache in key_part Date: Thu, 1 Nov 2018 16:32:22 +0300 [thread overview] Message-ID: <20181101133222.GB30032@chai> (raw) In-Reply-To: <a6ad1a637143074cd3d30d06914168754fae08a0.1540795996.git.kshcherbatov@tarantool.org> * Kirill Shcherbatov <kshcherbatov@tarantool.org> [18/10/29 20:25]: > Same key_part could be used in different formats multiple > times I don't understand this comment. Could you please rephrase? key_part is a part of key_def. How can it be used in a format at all? >, so different field->offset_slot would be allocated. > In most scenarios we work with series of tuples of same > format, and (in general) format lookup for field would be > expensive operation for JSON-paths defined in key_part. I don't understand this statement either. Could you give an example? > New offset_slot_cache field in key_part structure and epoch-based > mechanism to validate it's actuality should be effective > approach to improve performance. Did you consider storing it elsewhere, e.g. in some kind of index search context? > - alter->new_space = space_new_xc(alter->space_def, &alter->key_list); > + alter->new_space = > + space_new_xc(alter->space_def, &alter->key_list, > + alter->old_space->format != NULL ? > + alter->old_space->format->epoch + 1 : 1); Can't we make it simpler and simply increase epoch id every time we create a new space? This is only an optimization, by leaking it into alter.cc you are making alter worry about stuff which should not be its concern. > + struct space *space = engine_create_space(engine, def, key_list, epoch); Passing epoch id around explicitly is ugly. > - key_def_set_part(new_def, pos++, part->fieldno, part->type, > + key_def_set_part(new_def, pos, part->fieldno, part->type, > part->nullable_action, part->coll, > part->coll_id, part->sort_order, part->path, > part->path_len); > + new_def->parts[pos].offset_slot_cache = part->offset_slot_cache; > + new_def->parts[pos].format_cache = part->format_cache; > + pos++; Why can't you do it in key_def_set_part? > - key_def_set_part(new_def, pos++, part->fieldno, part->type, > + key_def_set_part(new_def, pos, part->fieldno, part->type, > part->nullable_action, part->coll, > part->coll_id, part->sort_order, part->path, > part->path_len); > + new_def->parts[pos].offset_slot_cache = part->offset_slot_cache; > + new_def->parts[pos].format_cache = part->format_cache; > + pos++; Lack of code reuse, abstraction leak. > +++ b/src/box/key_def.h > @@ -101,6 +101,14 @@ struct key_part { > char *path; > /** The length of JSON path. */ > uint32_t path_len; > + /** > + * Source format for offset_slot_cache actuality > + * validations. Cache is expected to use "the format with The source format to check that offset_slot_epoch is not stale. Please avoid using the word "actuality". > + * the newest epoch is most relevant" strategy. > + */ > + struct tuple_format *format_cache; > + /** Cache with format's field offset slot. */ > + int32_t offset_slot_cache; > }; > -- Konstantin Osipov, Moscow, Russia, +7 903 626 22 32 http://tarantool.io - www.twitter.com/kostja_osipov
next prev parent reply other threads:[~2018-11-01 13:32 UTC|newest] Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-10-29 6:56 [PATCH v5 00/12] box: indexes by JSON path Kirill Shcherbatov 2018-10-29 6:56 ` [PATCH v5 01/12] box: refactor key_def_find routine Kirill Shcherbatov 2018-11-19 17:48 ` Vladimir Davydov 2018-10-29 6:56 ` [PATCH v5 10/12] box: tune tuple_field_raw_by_path for indexed data Kirill Shcherbatov 2018-10-29 6:56 ` [PATCH v5 11/12] box: introduce offset slot cache in key_part Kirill Shcherbatov 2018-11-01 13:32 ` Konstantin Osipov [this message] 2018-11-06 12:15 ` [tarantool-patches] " Kirill Shcherbatov 2018-10-29 6:56 ` [PATCH v5 12/12] box: specify indexes in user-friendly form Kirill Shcherbatov 2018-11-01 13:34 ` [tarantool-patches] " Konstantin Osipov 2018-11-01 14:18 ` Konstantin Osipov 2018-11-06 12:15 ` [tarantool-patches] " Kirill Shcherbatov 2018-10-29 6:56 ` [PATCH v5 02/12] box: introduce key_def_parts_are_sequential Kirill Shcherbatov 2018-11-01 14:23 ` [tarantool-patches] " Konstantin Osipov 2018-11-06 12:14 ` [tarantool-patches] " Kirill Shcherbatov 2018-11-19 17:48 ` Vladimir Davydov 2018-10-29 6:56 ` [PATCH v5 03/12] box: introduce tuple_field_go_to_path Kirill Shcherbatov 2018-11-19 17:48 ` Vladimir Davydov 2018-10-29 6:56 ` [PATCH v5 04/12] box: introduce tuple_format_add_key_part Kirill Shcherbatov 2018-11-01 14:38 ` [tarantool-patches] " Konstantin Osipov 2018-11-06 12:15 ` [tarantool-patches] " Kirill Shcherbatov 2018-11-19 17:50 ` Vladimir Davydov 2018-10-29 6:56 ` [PATCH v5 05/12] lib: implement JSON tree class for json library Kirill Shcherbatov 2018-11-01 15:08 ` [tarantool-patches] " Konstantin Osipov 2018-11-06 12:15 ` [tarantool-patches] " Kirill Shcherbatov 2018-11-19 17:53 ` Vladimir Davydov 2018-11-20 16:43 ` Vladimir Davydov 2018-11-21 10:37 ` [tarantool-patches] " Kirill Shcherbatov 2018-11-26 10:50 ` Kirill Shcherbatov 2018-10-29 6:56 ` [PATCH v5 06/12] box: manage format fields with JSON tree class Kirill Shcherbatov 2018-10-29 6:56 ` [PATCH v5 07/12] lib: introduce json_path_normalize routine Kirill Shcherbatov 2018-11-01 15:22 ` [tarantool-patches] " Konstantin Osipov 2018-11-01 15:27 ` [tarantool-patches] " Kirill Shcherbatov 2018-11-20 15:13 ` Vladimir Davydov 2018-11-26 10:50 ` Kirill Shcherbatov 2018-11-20 15:14 ` Vladimir Davydov 2018-10-29 6:56 ` [PATCH v5 08/12] box: introduce JSON indexes Kirill Shcherbatov 2018-11-20 16:52 ` Vladimir Davydov 2018-11-26 10:50 ` [tarantool-patches] " Kirill Shcherbatov 2018-10-29 6:56 ` [tarantool-patches] [PATCH v5 09/12] box: introduce has_json_paths flag in templates 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=20181101133222.GB30032@chai \ --to=kostja@tarantool.org \ --cc=kshcherbatov@tarantool.org \ --cc=tarantool-patches@freelists.org \ --cc=vdavydov.dev@gmail.com \ --subject='Re: [tarantool-patches] [PATCH v5 11/12] box: introduce offset 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