Hi guy :) thanks for answering so fast! there's others two mdev too that i sent some patchs 1) mdev-6766 some status variables counters, and two variables to 'tune' try_lock of query cache, query_cache_write_timeout and query_cache_read_timeout, the today value is hard coded to 50ms, some benchmarks shows that the 'default' value could be lower, well just a tune parameter as many others based in time could be changed to different workloads 2) mdev-6631 (only check query cache quereis that use SQL_CACHE when query_cache_type=DEMAND i don't know if should be nice to include a DEMAND_NO_PRUNE, when old queries are included at query cache using query_cache_type=ON and after that switch to query_cache_type=DEMAND could block query cache from fetching old queries that are inside query cache, any way, i see the solution very nice, only queries that MUST be cached are cached and only queries with SQL_CACHE are seek inside query cache, this reduce a lot lock contention while searching and writing to query cache both at github ​ others ideas are about changing query cache and lock use, maybe should be part of a rewriting the query cache code i use aria/myisam/innodb, when using aria/myisam i take advantage from insert concurrency, in other words i could execute concurrent insert and select queries, i think that this could be used at query cache, i don't know what exactly should be changed but could be nice a lockfree include of result blocks while the query information block stay as 'writing' status, and after all blocks write change it to 'done' status, just an idea (i don't knwo if this coudl work), other idea could be batch inserts like group commit, and the last one is dynamic block size (i think we have a mdev for this were i told to try use of SQL_SMALL_RESULT and SQL_BIG_RESULT or LIMIT) i think that's all thanks =]