- developers - lists.mariadb.org

[Maria-developers] Step#4: MDEV-7950 Item_func::type() takes 0.26% in OLTP RO
by Alexander Barkov 13 May '15

13 May '15

Hi Sergey, Please review a patch for the next step for MDEV-7950 (one small thing at a time, to avoid huge unclear patches) Thanks.

2 4

Re: [Maria-developers] 7feee74: MDEV-7943 - pthread_getspecific() takes 0.76% in OLTP RO
by Sergei Golubchik 12 May '15

12 May '15

Hi, Sergey! On Apr 22, svoj(a)mariadb.org wrote: > revision-id: 7feee74dd30c96bd50d1c90e4ce3b06a656b17a5 > parent(s): 696188fe2f0756a98914df5b95ba302f7e5c55df > committer: Sergey Vojtovich > branch nick: mariadb > timestamp: 2015-04-22 13:29:56 +0400 > message: > > MDEV-7943 - pthread_getspecific() takes 0.76% in OLTP RO > > Added THD argument to select_result and all derivative classes. This > reduces number of pthread_getspecific calls from 796 to 776 per OLTP > RO transaction. Lots of changes for a little gain :) Ok to push. An idea. Create a variant of Sql_alloc (say, Sql_alloc_explicit, a parent of Sql_alloc) that does not use current_thd but requires MEM_ROOT to be specified explicitly. And use it for classes where you want it. Regards, Sergei

2 1

[Maria-developers] MariaDB Debian deprecation policy
by Daniel Bartholomew 11 May '15

11 May '15

Looking for input on this. On the MariaDB Deprecation Policy page we list planned deprecation dates for most of the platforms we build on. https://mariadb.com/kb/en/mariadb/deprecation-policy/ The various Debian releases we build for are listed, but there are no deprecation dates. According to https://www.debian.org/releases/ with the release of Debian 8 "Jessie" both Squeeze and Wheezy are now "obsolete". Should we deprecate both of them and stop providing builds? Or should we just deprecate Squeeze? Thanks. -- Daniel Bartholomew, MariaDB Release Manager MariaDB | http://mariadb.com

3 3

Re: [Maria-developers] 0520a00: MDEV-7964 - delete_dynamic() takes 0.12% in OLTP RO
by Sergei Golubchik 10 May '15

10 May '15

Hi, Sergey! On Apr 16, svoj(a)mariadb.org wrote: > revision-id: 0520a009c7139c940ab92345054bf0dba7808b11 > parent(s): eb059cd41e5553597f81fd90ad55c07d76d317ce > committer: Sergey Vojtovich > branch nick: mariadb > timestamp: 2015-04-16 18:38:26 +0400 > message: > > MDEV-7964 - delete_dynamic() takes 0.12% in OLTP RO ... > diff --git a/sql/sql_base.cc b/sql/sql_base.cc > index 0e9f668..d36de7f 100644 > --- a/sql/sql_base.cc > +++ b/sql/sql_base.cc > @@ -4240,9 +4233,17 @@ thr_lock_type read_lock_type_for_table(THD *thd, > DBUG_RETURN(true); > } > > - if (! (flags & MYSQL_OPEN_SKIP_SCOPED_MDL_LOCK) && > - schema_set.insert(table)) > - DBUG_RETURN(TRUE); > + /* Scoped locks: Take intention exclusive locks on all involved schemas. */ > + if (!(flags & MYSQL_OPEN_SKIP_SCOPED_MDL_LOCK)) > + { > + MDL_request *schema_request= new (thd->mem_root) MDL_request; > + if (schema_request == NULL) > + DBUG_RETURN(TRUE); > + schema_request->init(MDL_key::SCHEMA, table->db, "", > + MDL_INTENTION_EXCLUSIVE, > + MDL_TRANSACTION); > + mdl_requests.push_front(schema_request); > + } As far as I understand, the Hash_set was used here to make only one MDL request per schema. Now if you'll have 10 tables all in one schema, you'll make push 10 MDL requests instead of one. Which may be fine, if MDL subsystem places only one lock in this case (iirc, it does). But what is cheaper - collapse identical schemas into one mdl request here (with Hash_set) or let mdl sort it out later? > mdl_requests.push_front(&table->mdl_request); > } Regards, Sergei

2 4

Re: [Maria-developers] [Commits] 845edb6: MDEV-7067: Server outputs Galera (WSREP) information, even if Galera is disabled
by Sergei Golubchik 09 May '15

09 May '15

Hi, Nirbhay! On Apr 08, Nirbhay Choubey wrote: > revision-id: 845edb6259559bed39eb7365860aa5d588990775 > parent(s): 3674c363a7e77e534c3e0d28659dc614c53fbcbc > committer: Nirbhay Choubey > branch nick: 10.1-wsrep > timestamp: 2015-04-08 16:49:57 -0400 > message: > > MDEV-7067: Server outputs Galera (WSREP) information, even if Galera is disabled > > - mysqld_safe: Skip wsrep position recovery if wsrep_on variable > (mandatory since 10.1) is not specified ok > - Do not load "dummy" wsrep provider if wsrep_on is not ON see below > - Remove "-wsrep" from server version ok I'd also move "wsrep_25.10.r4144" from version_comment to a separate variable, like, wsrep_version. > diff --git a/sql/wsrep_var.cc b/sql/wsrep_var.cc > index ca921b7..1cd0a54 100644 > --- a/sql/wsrep_var.cc > +++ b/sql/wsrep_var.cc > @@ -295,6 +295,8 @@ bool wsrep_provider_options_check(sys_var *self, THD* thd, set_var* var) > > bool wsrep_provider_options_update(sys_var *self, THD* thd, enum_var_type type) > { > + if (!wsrep) return false; > + What about that comment by Alexey Yurchenko? The one where he says that checking for wsrep being not NULL inside wsrep functions is never needed, because wsrep functions should be never even called if wsrep is not enabled. Regards, Sergei

2 1

Re: [Maria-developers] ceae9ba: MDEV-7999 - PROFILING routines take 0.2% when profiling disabled
by Sergei Golubchik 09 May '15

09 May '15

Hi, Sergey! On Apr 15, svoj(a)mariadb.org wrote: > revision-id: ceae9ba7c8872d6558b331ef1ed1ebef42ecdc19 > parent(s): 367f043248112394bd1dc05c72d2844d217a4d55 > committer: Sergey Vojtovich > branch nick: mariadb > timestamp: 2015-04-15 18:12:23 +0400 > message: > > MDEV-7999 - PROFILING routines take 0.2% when profiling disabled Ok to push. One question: > diff --git a/sql/sql_profile.cc b/sql/sql_profile.cc > index 2eaaea4..9fa4d64 100644 > --- a/sql/sql_profile.cc > +++ b/sql/sql_profile.cc > @@ -720,4 +665,10 @@ int PROFILING::fill_statistics_info(THD *thd_arg, TABLE_LIST *tables, Item *cond > DBUG_RETURN(0); > } > + > + > +void PROFILING::reset() > +{ > + enabled= thd->variables.option_bits & OPTION_PROFILING; > +} Why is this not inlined? Regards, Sergei

2 1

Re: [Maria-developers] eb059cd: MDEV-8001 - mysql_reset_thd_for_next_command() takes 0.04% in OLTP RO
by Sergei Golubchik 09 May '15

09 May '15

Hi, Sergey! On Apr 15, svoj(a)mariadb.org wrote: > revision-id: eb059cd41e5553597f81fd90ad55c07d76d317ce > parent(s): ceae9ba7c8872d6558b331ef1ed1ebef42ecdc19 > committer: Sergey Vojtovich > branch nick: mariadb > timestamp: 2015-04-15 18:32:34 +0400 > message: > > MDEV-8001 - mysql_reset_thd_for_next_command() takes 0.04% in OLTP RO ok to push > Removed mysql_reset_thd_for_next_command(). Call THD::reset_for_next_command() > directly instead. > > mysql_reset_thd_for_next_command() overhead dropped 0.04% -> out of radar. > THD::reset_for_next_command() overhead didn't increase. Sure, why would it increase? Regards, Sergei

2 1

[Maria-developers] what could be better than %1 OLTP test gains?
by Daniel Black 09 May '15

09 May '15

Appreciate all the effort recently to save <1% on OLTP tests. MDEV-6735 / MDEV-7786 has a 3 line patch in progress that saves a 6700% (0.1 seconds to 11 min 10.44 sec) by changing optimizer decision based on something more meaningful than an absolute number of rows on one side of a join (a specific tuning for some test at some time?). Sure it might not make someone's blog (though it should), but it will make it possible to move one customer of mine beyond 5.5.32 which is near where a regression happened and for all those Magento users who've chosen MariaDB where performance has just broken to unusable when 100 categories was exceeded. -- -- Daniel Black, Engineer @ Open Query (http://openquery.com.au) Remote expertise & maintenance for MySQL/MariaDB server environments.

1 0

Re: [Maria-developers] 696188f: MDEV-7951 - sql_alloc() takes 0.25% in OLTP RO
by Sergei Golubchik 08 May '15

08 May '15

Hi, Sergey! On Apr 17, svoj(a)mariadb.org wrote: > revision-id: 696188fe2f0756a98914df5b95ba302f7e5c55df > parent(s): 0520a009c7139c940ab92345054bf0dba7808b11 > committer: Sergey Vojtovich > branch nick: mariadb > timestamp: 2015-04-17 14:30:15 +0400 > message: > > MDEV-7951 - sql_alloc() takes 0.25% in OLTP RO > > sql_alloc() has additional costs compared to direct mem_root allocation: > - function call: it is defined in a separate translation unit and can't be > inlined > - it needs to call pthread_getspecific() to get THD::mem_root > > It is called dozens of times implicitely at least by: > - List<>::push_back() > - List<>::push_front() > - new (for Sql_alloc derived classes) > - sql_memdup() > > Replaced lots of implicit sql_alloc() calls with direct mem_root allocation, > passing through THD pointer whenever it is needed. > > Number of sql_alloc() calls reduced 345 -> 41 per OLTP RO transaction. > pthread_getspecific() overhead dropped 0.76 -> 0.59 > sql_alloc() overhed dropped 0.25 -> 0.06 ok to push Regards, Sergei

1 0

Re: [Maria-developers] d116e02: MDEV-7945 - THD::enter_stage() takes 0.48% in OLTP RO
by Sergei Golubchik 08 May '15

08 May '15

Hi, Sergey! On Apr 14, svoj(a)mariadb.org wrote: > revision-id: d116e028a9545af8bd9eeb03f2ce0e56a9c455f9 > parent(s): 201c985be56f375677df9275d38f18a20cf41029 > committer: Sergey Vojtovich > branch nick: mariadb > timestamp: 2015-04-14 17:52:08 +0400 > message: > > MDEV-7945 - THD::enter_stage() takes 0.48% in OLTP RO > > THD::enter_stage() optimizations: > - stage backup code moved to THD::backup_stage(), saves one condition > - moved check for "new_stage" out to callers that actually need it > - remnants of enter_stage() moved to sql_class.h so it can be inlined > > THD::enter_stage() overhead dropped 0.48% -> 0.07%. > > PROFILING::status_change() optimizations: > - no need to check "status_arg": it is checked by caller anyway > - no need to check "enabled": !enabled && current is impossible > - remnants of status_change() moved to sql_profile.h so it can be inlined > > PROFILING::status_change() overhead dropped 0.1% -> out of radar. ok to push Regards, Sergei

1 0