maria-developers team mailing list archive

[Oleksandr Byelkin <sanja@xxxxxxxxxxxxxxxx>]

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]