From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org> To: tarantool-patches@freelists.org, Kirill Shcherbatov <kshcherbatov@tarantool.org>, Konstantin Osipov <kostja@tarantool.org> Subject: [tarantool-patches] Re: [PATCH v5 3/6] sql: introduce tuple_fetcher class Date: Mon, 3 Jun 2019 23:15:10 +0200 [thread overview] Message-ID: <bb2fc775-ab8b-66e7-b26a-2d89420722fd@tarantool.org> (raw) In-Reply-To: <20c02296-1a80-a384-cafa-c061f51ad31d@tarantool.org> Hi! Thanks for the fixes! See 2 comments below, review fixes on the branch, and at the end of the email. > commit 80251ea01b0eeca9cf8bcb50f4b97d97bbcb41ca > Author: Kirill Shcherbatov <kshcherbatov@tarantool.org> > Date: Mon May 20 19:28:42 2019 +0300 > > sql: introduce vdbe_field_ref class > > Refactored OP_Column instruction with a new vdbe_field_ref class. > The vdbe_field_ref is a reusable object that speed-up field 1. 'speed' -> 'speeds'. > access for given tuple or tuple data. > Introduced OP_Fetch opcode that uses tuple_fetcher given as a 2. There are no 'tuple_fetcher' anymore. > first argument. This opcode makes possible to perform binding > of a new tuple to an existent VDBE without decoding it's fields. > > Needed for #3691 > I've pushed my review fixes in a separate commit. I didn't fix the commit message, because I can't do it without amendment. Below are my explanations, and diff. 1) I fixed indentation and width > 80. 2) I renamed vdbe_field_ref_tuple_field_fast to vdbe_field_ref_fast_fetch. I didn't like tautology with word 'field' used twice. 3) I dropped a couple of very outdated comments from fetch() function. 4) I fixed a comment for OP_Fetch with declared but unused P4 and P5. 5) I renames field_idx to fieldno in fetch() to be consistent with fast_fetch(). On the whole, the patch is great, even without CHECKs stuff. It strongly improves tuples integration into Vdbe, which beforehand treated them as mere arrays. ================================================================== diff --git a/src/box/sql.c b/src/box/sql.c index b4702fd78..f7b90ab5c 100644 --- a/src/box/sql.c +++ b/src/box/sql.c @@ -1368,7 +1368,7 @@ vdbe_field_ref_create(struct vdbe_field_ref *field_ref, struct tuple *tuple, void vdbe_field_ref_prepare_data(struct vdbe_field_ref *field_ref, const char *data, - uint32_t data_sz) + uint32_t data_sz) { vdbe_field_ref_create(field_ref, NULL, data, data_sz); } @@ -1377,5 +1377,6 @@ void vdbe_field_ref_prepare_tuple(struct vdbe_field_ref *field_ref, struct tuple *tuple) { - vdbe_field_ref_create(field_ref, tuple, tuple_data(tuple), tuple->bsize); + vdbe_field_ref_create(field_ref, tuple, tuple_data(tuple), + tuple->bsize); } diff --git a/src/box/sql.h b/src/box/sql.h index 066a0d322..3056d8f7e 100644 --- a/src/box/sql.h +++ b/src/box/sql.h @@ -430,7 +430,7 @@ struct vdbe_field_ref { */ void vdbe_field_ref_prepare_data(struct vdbe_field_ref *field_ref, const char *data, - uint32_t data_sz); + uint32_t data_sz); /** * Initialize a new vdbe_field_ref instance with given tuple diff --git a/src/box/sql/vdbe.c b/src/box/sql/vdbe.c index 256ee77a0..3f0b856b3 100644 --- a/src/box/sql/vdbe.c +++ b/src/box/sql/vdbe.c @@ -623,8 +623,8 @@ mem_type_to_str(const struct Mem *p) * offset to @a fieldno. */ static const void * -vdbe_field_ref_tuple_field_fast(struct vdbe_field_ref *field_ref, - uint32_t fieldno, uint32_t *field_size) +vdbe_field_ref_fast_fetch(struct vdbe_field_ref *field_ref, uint32_t fieldno, + uint32_t *field_size) { if (field_ref->tuple == NULL) return NULL; @@ -641,38 +641,30 @@ vdbe_field_ref_tuple_field_fast(struct vdbe_field_ref *field_ref, } /** - * Fetch field by field_idx using vdbe_field_ref and store result + * Fetch field by fieldno using vdbe_field_ref and store result * in dest_mem. * @param field_ref The initialized vdbe_field_ref instance to use. - * @param field_idx The id of the field to fetch. + * @param fieldno The id of the field to fetch. * @param[out] dest_mem The memory variable to store result. * @retval SQL_OK Status code in case of success. * @retval sql_ret_code Error code otherwise. */ static int -vdbe_field_ref_fetch(struct vdbe_field_ref *field_ref, uint32_t field_idx, - struct Mem *dest_mem) +vdbe_field_ref_fetch(struct vdbe_field_ref *field_ref, uint32_t fieldno, + struct Mem *dest_mem) { sqlVdbeMemSetNull(dest_mem); uint32_t *slots = field_ref->slots; - if (field_idx >= field_ref->field_count) { + if (fieldno >= field_ref->field_count) { UPDATE_MAX_BLOBSIZE(dest_mem); return SQL_OK; } - /* - * Make sure at least the first field_idx + 1 entries - * of the header have been parsed and valid information - * is in field_map[]. - * If there is more header available for parsing in the - * record, try to extract additional fields up through the - * field_map+1-th field. - */ const char *data; - if (field_ref->rightmost_slot <= field_idx) { + if (field_ref->rightmost_slot <= fieldno) { uint32_t field_sz; - data = vdbe_field_ref_tuple_field_fast(field_ref, field_idx, - &field_sz); + data = vdbe_field_ref_fast_fetch(field_ref, fieldno, + &field_sz); if (data != NULL) { /* * Special case for tarantool spaces: for @@ -685,27 +677,22 @@ vdbe_field_ref_fetch(struct vdbe_field_ref *field_ref, uint32_t field_idx, * visited in mp_next() cycle. */ uint32_t offset = (uint32_t)(data - field_ref->data); - slots[field_idx] = offset; - slots[field_idx + 1] = offset + field_sz; + slots[fieldno] = offset; + slots[fieldno + 1] = offset + field_sz; } else { uint32_t i = field_ref->rightmost_slot; data = field_ref->data + slots[i]; do { mp_next(&data); slots[++i] = (uint32_t)(data - field_ref->data); - } while (i <= field_idx); + } while (i <= fieldno); field_ref->rightmost_slot = i; } } - /* - * Extract the content for the p2+1-th column. Control - * can only reach this point if field_map[field_idx], - * field_map[field_idx+1] are valid. - */ assert(sqlVdbeCheckMemInvariants(dest_mem) != 0); uint32_t dummy; - data = field_ref->data + slots[field_idx]; + data = field_ref->data + slots[fieldno]; if (vdbe_decode_msgpack_into_mem(data, dest_mem, &dummy) != 0) return SQL_TARANTOOL_ERROR; @@ -714,7 +701,7 @@ vdbe_field_ref_fetch(struct vdbe_field_ref *field_ref, uint32_t field_idx, * Wrap it in a blob verbatim. */ if (dest_mem->flags == 0) { - dest_mem->n = slots[field_idx + 1] - slots[field_idx]; + dest_mem->n = slots[fieldno + 1] - slots[fieldno]; dest_mem->z = (char *) data; dest_mem->flags = MEM_Blob | MEM_Ephem | MEM_Subtype; dest_mem->subtype = SQL_SUBTYPE_MSGPACK; @@ -723,7 +710,8 @@ vdbe_field_ref_fetch(struct vdbe_field_ref *field_ref, uint32_t field_idx, * Add 0 termination (at most for strings) * Not sure why do we check MEM_Ephem */ - if ((dest_mem->flags & (MEM_Ephem | MEM_Str)) == (MEM_Ephem | MEM_Str)) { + if ((dest_mem->flags & (MEM_Ephem | MEM_Str)) == + (MEM_Ephem | MEM_Str)) { int len = dest_mem->n; if (dest_mem->szMalloc < len + 1) { if (sqlVdbeMemGrow(dest_mem, len + 1, 1) != 0) @@ -2801,7 +2789,7 @@ op_column_out: break; } -/* Opcode: Fetch P1 P2 P3 P4 P5 +/* Opcode: Fetch P1 P2 P3 * * * Synopsis: r[P3]=PX * * Interpret data P1 points at as an initialized vdbe_field_ref
next prev parent reply other threads:[~2019-06-03 21:15 UTC|newest] Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-05-23 10:19 [tarantool-patches] [PATCH v5 0/6] box: run checks on insertions in LUA spaces Kirill Shcherbatov 2019-05-23 10:19 ` [tarantool-patches] [PATCH v5 1/6] sql: introduce a new method to bind a pointer Kirill Shcherbatov 2019-05-23 10:19 ` [tarantool-patches] [PATCH v5 2/6] sql: refactor OP_Column vdbe instruction Kirill Shcherbatov 2019-05-23 10:19 ` [tarantool-patches] [PATCH v5 3/6] sql: introduce tuple_fetcher class Kirill Shcherbatov 2019-05-26 12:05 ` [tarantool-patches] " Vladislav Shpilevoy 2019-05-31 13:45 ` Kirill Shcherbatov 2019-05-31 19:45 ` Konstantin Osipov 2019-05-31 19:50 ` Kirill Shcherbatov 2019-05-31 22:36 ` Vladislav Shpilevoy 2019-06-01 5:45 ` Konstantin Osipov 2019-06-02 18:50 ` Kirill Shcherbatov 2019-06-03 21:15 ` Vladislav Shpilevoy [this message] 2019-06-05 6:47 ` Konstantin Osipov 2019-06-05 6:48 ` Konstantin Osipov 2019-05-23 10:19 ` [tarantool-patches] [PATCH v5 4/6] schema: add new system space for CHECK constraints Kirill Shcherbatov 2019-05-26 12:06 ` [tarantool-patches] " Vladislav Shpilevoy 2019-05-26 13:31 ` n.pettik 2019-05-26 13:32 ` Vladislav Shpilevoy 2019-05-31 13:45 ` Kirill Shcherbatov 2019-06-03 21:15 ` Vladislav Shpilevoy 2019-05-23 10:19 ` [tarantool-patches] [PATCH v5 5/6] box: run check constraint tests on space alter Kirill Shcherbatov 2019-05-26 12:07 ` [tarantool-patches] " Vladislav Shpilevoy 2019-05-31 13:45 ` Kirill Shcherbatov 2019-06-03 21:15 ` Vladislav Shpilevoy 2019-05-23 10:19 ` [tarantool-patches] [PATCH v5 6/6] box: user-friendly interface to manage ck constraints Kirill Shcherbatov 2019-05-26 12:07 ` [tarantool-patches] " Vladislav Shpilevoy 2019-05-31 13:45 ` Kirill Shcherbatov 2019-06-03 21:15 ` [tarantool-patches] Re: [PATCH v5 0/6] box: run checks on insertions in LUA spaces Vladislav Shpilevoy 2019-06-04 7:21 ` Kirill Shcherbatov 2019-06-04 18:59 ` Vladislav Shpilevoy 2019-06-06 11:58 ` Kirill Yukhin
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=bb2fc775-ab8b-66e7-b26a-2d89420722fd@tarantool.org \ --to=v.shpilevoy@tarantool.org \ --cc=kostja@tarantool.org \ --cc=kshcherbatov@tarantool.org \ --cc=tarantool-patches@freelists.org \ --subject='[tarantool-patches] Re: [PATCH v5 3/6] sql: introduce tuple_fetcher class' \ /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