<div dir="auto">That’s great i’ll try this.</div><div dir="auto"><br></div><div dir="auto">Thanks a lot. </div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 15 Sep 2022 at 9:56 Tatsuo Ishii <<a href="mailto:ishii@sraoss.co.jp">ishii@sraoss.co.jp</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">> Ideally the process reading query cache should only grab a shared<br>
> lock, which will not block other reading process. Unfortunately we do<br>
> not have shared lock facility (we only have exclusive lock).<br>
<br>
I have created a proof of concept patch to implement the share lock<br>
using flock(2). Attached is a graph showing the benchmark result. The<br>
Y axis is the number of queries executed within 1 second. The X axis<br>
is the number of concurrent session.<br>
<br>
As you can see new implementation (enable query cache (flock,<br>
exclusive lock for update), green line) outperforms existing<br>
implementation using exclusive lock only (red line) as number of<br>
concurrent users increases. Note that this is somewhat extreme case<br>
because the cache hit ratio is 100% (i.e. exactly same query is used<br>
during the benchmark). So the difference will not be that big in the<br>
wild.<br>
<br>
The actual query used was:<br>
SELECT repeat('abcdefg', 500);<br>
<br>
The blue line is the case when query cache is disabled just for<br>
reference.<br>
<br>
The benchmark was performed on a Ubuntu 20 box with 16GB mem, 6 physical<br>
cores, 12 vcores.<br>
<br>
Best reagards,<br>
--<br>
Tatsuo Ishii<br>
SRA OSS LLC<br>
English: <a href="http://www.sraoss.co.jp/index_en/" rel="noreferrer" target="_blank">http://www.sraoss.co.jp/index_en/</a><br>
Japanese:<a href="http://www.sraoss.co.jp" rel="noreferrer" target="_blank">http://www.sraoss.co.jp</a><br>
</blockquote></div></div>