[MDEV-4584] QUERY CACHE - SQL Control Interface Created: 2013-05-26 Updated: 2015-10-29 |
|
| Status: | Open |
| Project: | MariaDB Server |
| Component/s: | Query Cache |
| Fix Version/s: | None |
| Type: | Task | Priority: | Trivial |
| Reporter: | roberto spadim | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | querycache, querycache_control | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||
| Description |
|
5 new SQL commands: 1)QUERY CACHE LOCK <TIMEOUT> let me explain: 1/2) 2) this set the query cache lock_connection_id to 0 and unlock query cache — 3) this remove the query inside query hash of query cache class that's in the position = 99999 (query_id) 4) this will remove queries in cache that use some table using "LIKE" operator to get table names 5) get the result of a query cached (something like internal changes.. well i don't know all we have to change but... somewhere in the end of query cache lock function: if lock_connection_id !=0, check if that connection is a dead connection or not check that we will lock all query cache system using SQL user interface... 2) unlock will just set lock_connection_id=0 when lock_connection_id = current connection_id with this, we can add a new feature of MDEV-4583 (query cache clean procedure) when query cache is full, we could call a user procedure and execute a user procedure to clean cache query_cache_clean_method=DEFAULT / PROCEDURE maybe we could create a new query_cache table with less information after accepting
Instead of a column in QUERY_CACHE_QUERIES table with a 'group_concat' column having tables like: `db_name`.`table_used1`, `db_name`.`table_used2` .. |
| Comments |
| Comment by roberto spadim [ 2013-06-20 ] |
|
wait accept this mdev, to continue development of query control, without it we can't select what query to remove from cache |
| Comment by Daniel Black [ 2015-10-29 ] |
|
Why is this needed? QUERY CACHE LOCK /UNLOCK its controlling internal locks and doesn't have an immediate use that I can see. No other internal lock is given explicit control to the user nor can I see anything using done in a locking period that shouldn't use the implicit behaviour. If the other commands here are useful they can implicitly lock the query cache (following the same paradigm as everything else in SQL - lock when there is a need). QUERY CACHE REMOVE <query_id> - why bother?, a less used query will be purged when space becomes short. If you didn't' want it cached you can use SELECT SQL_NO_CACHE... or demand based caching. QUERY CACHE REMOVE TABLE - why bother? cache invalidation based on table changes is automatic. QUERY CACHE RESULT - if you want the result of a query do the query. https://mariadb.com/kb/en/mariadb/aborting-statements/ has maximum execution time if you where trying to avoid long queries. |