Hi Sergei, On Tue, Nov 17, 2015 at 02:23:56PM +0100, Sergei Golubchik wrote: > Hi, Sergey! > > On Nov 17, Sergey Vojtovich wrote: > > revision-id: f21705dfbfcd87e46937222eb860727beb21a89b > > (mariadb-10.1.8-66-gf21705d) > > parent(s): c0216f1d02e63686f986fa8f352fdf6de61249a7 > > committer: Sergey Vojtovich > > timestamp: 2015-11-17 13:13:47 +0400 > > message: > > > > MDEV-7806 - thread_pool_size is not auto-sized > > > > thread_pool_size is auto-sized before my_getopt(). But my_getopt starts from > > resetting all options to their default values. So the auto-sized value is > > lost. > > > > Fixed by autosizing default value directly. > > > > diff --git a/sql/sys_vars.cc b/sql/sys_vars.cc > > index 682d803..e65a939 100644 > > --- a/sql/sys_vars.cc > > +++ b/sql/sys_vars.cc > > @@ -3270,7 +3270,7 @@ static Sys_var_uint Sys_threadpool_size( > > "This parameter is roughly equivalent to maximum number of concurrently " > > "executing threads (threads in a waiting state do not count as > > executing).", > > GLOBAL_VAR(threadpool_size), CMD_LINE(REQUIRED_ARG), > > - VALID_RANGE(1, MAX_THREAD_GROUPS), DEFAULT(8), BLOCK_SIZE(1), > > + VALID_RANGE(1, MAX_THREAD_GROUPS), DEFAULT(my_getncpus()), BLOCK_SIZE(1), > > NO_MUTEX_GUARD, NOT_IN_BINLOG, ON_CHECK(check_threadpool_size), > > ON_UPDATE(fix_threadpool_size) > > ); > > Strange solution. Why wouldn't you move autosizing after > config variables are read? Well, it's not a precedent: we already have similar solution for tc_log_size.
Wouldn't autosizing after config variables are read overwrite configured value? If so, we'll have to create special value for thread_pool_size, e.g. if value is 0 then do autosizing, preserve original value otherwise. I wouldn't mind if the above is preferred way. Thanks, Sergey _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
