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)...

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...

[skip]

Thanks Oleksandr, ideas?

Roberto Spadim