forked from docs/doc-exports
luhuayi
177cd61a57
Reviewed-by: Pruthi, Vineet <vineet.pruthi@t-systems.com> Co-authored-by: luhuayi <luhuayi@huawei.com> Co-committed-by: luhuayi <luhuayi@huawei.com>
24 lines
3.0 KiB
HTML
24 lines
3.0 KiB
HTML
<a name="EN-US_TOPIC_0000002022556380"></a><a name="EN-US_TOPIC_0000002022556380"></a>
|
|
|
|
<h1 class="topictitle1">Proactive Preheating and Tuning of Disk Cache</h1>
|
|
<div id="body0000002022556380"><p id="EN-US_TOPIC_0000002022556380__p13775115114257">This function is supported only in 9.1.0.200 or later.</p>
|
|
<div class="section" id="EN-US_TOPIC_0000002022556380__section33131524182115"><h4 class="sectiontitle">Overview</h4><p id="EN-US_TOPIC_0000002022556380__p1410017370211">In the storage-compute decoupling architecture, user data is stored in OBS to reduce storage costs. Each query generates network I/Os to retrieve data from OBS. To improve query speed, reduce storage costs, and minimize performance loss, the architecture provides disk cache capability. Pre-queried data is cached locally, enhancing performance.</p>
|
|
</div>
|
|
<p id="EN-US_TOPIC_0000002022556380__p8444101911817">The LRU2Q algorithm manages the disk cache with three queues: A1in, A1out, and Am. Data first enters A1in. If A1in is full (adjustable via a GUC parameter, default is 0.25 times the total queue size), data moves to A1out. Data enters Am only when hit in A1out. Am queue holds the hottest data.</p>
|
|
<p id="EN-US_TOPIC_0000002022556380__p1494130122111">For common queries, LRU2Q is sufficient. However, frequent joins of large and small tables can degrade performance if small tables are frequently evicted from A1in to A1out.</p>
|
|
<div class="section" id="EN-US_TOPIC_0000002022556380__section315412487225"><h4 class="sectiontitle">Tuning Syntax</h4><p id="EN-US_TOPIC_0000002022556380__p148671351132211">A new tuning policy allows directly adding small table data to Am, ensuring it remains hot and reducing network I/Os during joins. The syntax formats are as follows:</p>
|
|
</div>
|
|
<ol id="EN-US_TOPIC_0000002022556380__ol58211955152315"><li id="EN-US_TOPIC_0000002022556380__li08211558233">Perform the actual query and add data directly to Am.<pre class="screen" id="EN-US_TOPIC_0000002022556380__screen205832345407">explain warmup hot select ...; </pre>
|
|
<p id="EN-US_TOPIC_0000002022556380__p671762118404"><span><img id="EN-US_TOPIC_0000002022556380__image13717112174012" src="figure/en-us_image_0000002059501845.png"></span></p>
|
|
</li><li id="EN-US_TOPIC_0000002022556380__li3251187112413">Query data in the sequence A1in > A1out > Am.<pre class="screen" id="EN-US_TOPIC_0000002022556380__screen4839115912401">explain warmup select ...; </pre>
|
|
<p id="EN-US_TOPIC_0000002022556380__p16121104534017"><span><img id="EN-US_TOPIC_0000002022556380__image012174512400" src="figure/en-us_image_0000002023418392.png"></span></p>
|
|
</li><li id="EN-US_TOPIC_0000002022556380__li11733221162416">No actual query operation is performed, and the <strong id="EN-US_TOPIC_0000002022556380__b19617122262617">explain</strong> logic remains unchanged.<pre class="screen" id="EN-US_TOPIC_0000002022556380__screen14762103412411">explain select ...;</pre>
|
|
</li></ol>
|
|
</div>
|
|
<div>
|
|
<div class="familylinks">
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="dws_04_0445.html">Advanced SQL Tuning</a></div>
|
|
</div>
|
|
</div>
|
|
|