From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 18 Dec 2019 13:20:51 +0300 From: Kirill Yukhin Message-ID: <20191218102051.qgfa6nskqgrsqh4j@tarantool.org> References: <20191206113711.ctzr6x7sqbpr3xkd@tarantool.org> <20191206135009.GA6394@tarantool.org> <20191217221143.parwzoyb3e327sw5@tkn_work_nb> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20191217221143.parwzoyb3e327sw5@tkn_work_nb> Subject: Re: [Tarantool-patches] [PATCH v3 0/5] Replace control pragmas by SET List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Turenko Cc: tarantool-patches@dev.tarantool.org, v.shpilevoy@tarantool.org, tarantool-discussions@dev.tarantool.org, Peter Gulutzan Hello, On 18 дек 01:11, Alexander Turenko wrote: > Mergen, > > I don't have enough context here, but have questions about this > proposal. Sorry if they were already discussed and I missed it. > > Most important question is that I don't understand why we don't want to > provide language specific APIs for sessions settings. It looks both more > convenient and more performant. > > See this and other questions and notes below. > > (CCed Peter, because he may have some opinion how SQL API should look.) > > WBR, Alexader Turenko. > > ---- > > AFAIR discussions around a space / view for session settings arose from > Kostya O. proposal to move toward support of standard information schema > views (please, correct me, if I remember it wrongly). Then it becomes > out of scope somehow. But okay, let it being out. > > (BTW, I looked over SQL/Schemata 2011 and don't found anything like > MySQL's GLOBAL_VARIABLES and SESSION_VARIABLES tables. It seems there is > no standard table for session variables. I don't sure however.) > > ---- > > We have two basic variants: > > * Implement an API for session settings for each supported language > (C, Lua, SQL) and a protocol for connectors. > * Provide a system view / space (this is proposed by Mergen). > > First, a space / view is not most convenient way to operate on session > settings from a language. Let's compare. > > Lua: > > | box.space._vsession_settings:get({'sql_default_engine'}).value > | box.space._vsession_settings:update({'sql_default_engine'}, > | {{'=', 'value', 'vinyl'}}) > | > | box.session.settings:get('sql_default_engine') > | box.session.settings:set('sql_default_engine', 'vinyl') Frankly, to me this is not of big difference. Especially when we are talking about settings, references to which are rare. After all, one might want to implement setter to avoid such updates. > SQL: > > | SELECT "value" FROM "_vsession_settings" WHERE "name" = 'sql_default_engine' > | UPDATE "_vsession_settings" SET "value" = 'vinyl' \ > | WHERE "name" = 'sql_default_engine' > | > | SESSION GET 'sql_default_engine' > | SESSION SET 'sql_default_engine' = 'vinyl' > > C (sketchy): > > | /* Read from a _vsession_settings. */ > | > | enum { > | BOX_VSESSION_SETTINGS_VALUE_ID = 2 > | }; > | > | char key[32]; > | char *key_end = key; > | key_end = mp_encode_array(key_end, 1); > | key_end = mp_encode_str(key_end, "sql_default_engine", > | sizeof("sql_default_engine") - 1); > | > | box_tuple_t *tuple; > | box_iterator_t *it = box_index_iterator(BOX_VSESSION_SETTINGS_ID, 0, ITER_EQ, > | key, key_end); > | box_iterator_next(it, &tuple); > | const char *buf = box_tuple_field(tuple, BOX_VSESSION_SETTINGS_VALUE_ID); > | > | uint32_t engine_len; > | const char *engine = mp_decode_str(&buf, &engine_len); > | > | box_iterator_free(it); > | > | /* Update a value in _vsession_settings. */ > | > | > | > | /* Get and set with a language aware API. */ > | > | uint32_t engine_len; > | const char *engine = box_session_get_str(SESSION_SQL_DEFAULT_ENGINE, > | &engine_len); > | > | box_session_set_str(SESSION_SQL_DEFAULT_ENGINE, "vinyl", > | sizeof("vinyl") - 1); > > Languare-aware APIs above are just examples. I propose to implement such > APIs, but not how they should look exactly. This might have sense, but I'd treat it as a follow up activity. > To sum the examples up: it seems for me that language aware APIs are a > way more simple for a user. > > Second, all tuples are msgpack encoded (at least now). So any get/set > operation on _vspace_settings will require to encode and decode msgpack > (yep, both encode and decode at once). It will be surely less performant > then a hashmap lookup (session id -> struct session_settings) plus a > field access. > > So, language aware API can be implemented in more performant way then > general space-like one. I think performance out of scope here at all. > It seems that we anyway need an API for connectors. So we can provide > the proposed view, but don't use it internally to implement language > specific APIs (for performance). > > Console session settings (like statements delimiter, input language, > output format) are out of scope here? Yes. To sum up. We spent too much time here. I think we can improve approaches in future. But I see no serious reasons for that: 1. To make it easier to use we might whant to implement some stored routines or something/ 2. Performance of encode/decode is out of intereset here. I propose you to file a feature request as follow up of the patchset. -- Regards, Kirill Yukhin