← Back to team overview

maria-developers team mailing list archive

Re: RFC - query cache insert

 

07.08.2013 18:44, Roberto Spadim пишет:
Hi Oleksandr!

  humm i will check the source and understand how it is done,
thanks oleksandr!

but... another doubt...

today query cache have:
query blocks (with query and flags),
table blocks (with tables)
result blocks (with results)
there's any way of two query blocks (or more) link to same result block?


If it would be inexpensive way to detect query with same semantic why do
not put them as one query? Why all that complications with linking the same
result (and same tables BTW)?

hum, are you talking about rewrite the source of queries (applications)? i
think it's more complicate for some closed applications, i'm not thinking
like a application developer now, i'm thinking like a dba.
about links... that's how query cache works today, or not? at least three
kind of blocks, one for queries and flags other for table and other for
results, that's how qc_info plugin works at least
about a new kind of blocks... 'raw' query will not be the same of a
'normalized' query (at most cases at least) I think separated blocks for
each kind of query is nice, and allow a faster query hit for parser (expend
less time at parsers qc hit)...
Sorry I did not understand above, but it is not important (see below).
But there is no inexpensive way to detect it (re-printing query is quite
expensive if we will do it for each query). I hope it explain everything.

yes it is expensive, but the idea isn't execute for each query, the "first
version" will do it for every query (no problem), after some tunes could
allow to enable / disable this cost, example
the query size (number of bytes in query)
number of truples (i don't remember the name, but that's the "field
operator field" in WHERE and HAVING clauses
number of tables,
time expend in parser,
or a SQL_CACHE_EXTENDED option to force a cache (in this case will only
work for new applications)

i didn't checked the time/cpu expend with rewriting queries (i didn't found
this in source yet, but with time is will find),
the numbers that i have are:
1)query cache hit is < 0,1ms for a query cache with more than 10000 queries
and a relative small database with 300qps (queries per second)
2)query execution is more than >1ms in many disks (with some buffer / cache
it is faster)

if rewrite is near 1ms, i think that's ok in some kind of workloads (a
database with 10000qps maybe isn't good), but again, 1ms is better than
reading disk...
There is other big flaw in your idea.

When we return result from QC we do it _BEFORE_ parsing (and it is the QC huge advantage), so it is impossible to print the query in unified form. To do it we should parse it.


[skip]



Follow ups

References