Tarantool development patches archive
 help / color / mirror / Atom feed
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.

  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