Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
M
MariaDB
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Analytics
Analytics
CI / CD
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
nexedi
MariaDB
Commits
01637eba
Commit
01637eba
authored
Dec 12, 2001
by
arjen@co3064164-a.bitbike.com
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Some improvements to Query Cache text (by Colin Faber).
parent
73628811
Changes
1
Show whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
9 additions
and
8 deletions
+9
-8
Docs/manual.texi
Docs/manual.texi
+9
-8
No files found.
Docs/manual.texi
View file @
01637eba
...
...
@@ -34298,14 +34298,15 @@ Following are some performance data for the query cache
@itemize @bullet
@item
If you don't use the query cache (@code{query_cache_size=0}), there is
no notable overhead.
@item
If all queries are very simple (like selecting a row from a table with
one row) but still different so that the queries can't be cached, the
overhead for having the query cache active is 13%. This could be
regarded as the worst case scenario. In real life queries are much more
complicated than this so the overhead is normally significantly lower.
If want to disable the query cache code set @code{query_cache_size=0}.
By disabling the query cache code there is no noticeable overhead.
@item
If all of the queries you're preforming are simple (such as selecting a
row from a table with one row); but still differ so that the queries can
not be cached, the overhead for having the query cache active is 13%.
This could be regarded as the worst case scenario. However, in real life,
queries are much more complicated than our simple example so the overhead
is normally significantly lower.
@item
Searches after one row in a one row table is 238% faster.
This can be regarded as close to the minimum speedup to be expected for
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment