[MDEV-6359] QUERY CACHE - Dynamic query_cache_min_res_unit Created: 2014-06-18  Updated: 2015-01-23

Status: Open
Project: MariaDB Server
Component/s: Query Cache
Fix Version/s: None

Type: Task Priority: Trivial
Reporter: BELUGABEHR Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: querycache


 Description   

The Query Cache could perhaps benefit from a smarter, dynamic, query_cache_min_res_unit. In fact, it may be more useful to come up with a dynamic algorithm, per query, to determine the size of a allocation block, and enforce a "query_cache_MAX_res_unit".

SELECT COUNT(1) FROM test - Allocation block should be tiny
SELECT * FROM test - Allocation block might be "Avg_row_length" from table stats
SELECT col1, col2 FROM test - Allocation block might be "Avg_row_length" from table stats
SELECT col1 FROM test - Allocation block might be "Avg_row_length" from table stats

For more complicated queries where a reasonable estimate isn't possible, or cases where the "average_row_length" is large, use the max_res_unit.



 Comments   
Comment by Sergei Golubchik [ 2014-06-20 ]

sanja, what do you think about it?

Comment by Oleksandr Byelkin [ 2014-06-20 ]

The tiny block is evil thing (lead to fragmentation), but detection of huge results could be useful. AFAIK after optimization and before execution (i.e. before allocation first data block) we know size of the result record (without blobs) and estimation for number of rows.

Comment by Oleksandr Byelkin [ 2014-06-24 ]

Problems:

  • optimizer interested more in read records then send
  • optimizer gives upper limit estimation and in most cases it is more then will be sent to client
  • then more tables in upper join then less accurate is estimaion
  • we can say nothing about accuracy of estimation
Comment by roberto spadim [ 2014-09-22 ]

we could use SQL_SMALL_RESULT and SQL_BIG_RESULT flags and LIMIT at least?

Generated at Thu Feb 08 07:11:18 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.