maria-developers team mailing list archive

[Roberto Spadim <roberto@xxxxxxxxxxxxx>]

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 =]