forked from docs/doc-exports
Lu, Huayi
a24ca60074
Reviewed-by: Hasko, Vladimir <vladimir.hasko@t-systems.com> Co-authored-by: Lu, Huayi <luhuayi@huawei.com> Co-committed-by: Lu, Huayi <luhuayi@huawei.com>
18 lines
3.6 KiB
HTML
18 lines
3.6 KiB
HTML
<a name="EN-US_TOPIC_0000001145510811"></a><a name="EN-US_TOPIC_0000001145510811"></a>
|
|
|
|
<h1 class="topictitle1">GIN Tips and Tricks</h1>
|
|
<div id="body8662426"><p id="EN-US_TOPIC_0000001145510811__a90da7b3930d44104b9491695d76663ed">Create vs. Insert</p>
|
|
<p id="EN-US_TOPIC_0000001145510811__a4359501ae37d4e2785faadb65c3e31a9">Insertion into a GIN index can be slow due to the likelihood of many keys being inserted for each item. So, for bulk insertions into a table, it is advisable to drop the GIN index and recreate it after finishing the bulk insertions. GUC parameters related to GIN index creation and query performance as follows:</p>
|
|
<ul id="EN-US_TOPIC_0000001145510811__u1d50bf7c16294e018e8d6fac78e4cbb8"><li id="EN-US_TOPIC_0000001145510811__lda05b13014c841e4acc40141c3d87d9b">maintenance_work_mem<p id="EN-US_TOPIC_0000001145510811__a389034225d044364bd6750a97c9c7654"><a name="EN-US_TOPIC_0000001145510811__lda05b13014c841e4acc40141c3d87d9b"></a><a name="lda05b13014c841e4acc40141c3d87d9b"></a>Build time for a GIN index is very sensitive to the <strong id="EN-US_TOPIC_0000001145510811__b842352706153124">maintenance_work_mem</strong> setting.</p>
|
|
</li><li id="EN-US_TOPIC_0000001145510811__l8ea2b7aa52d74496a2cef4000e587600">work_mem<p id="EN-US_TOPIC_0000001145510811__a67ad5839bd7944ccace34659f0c0e527"><a name="EN-US_TOPIC_0000001145510811__l8ea2b7aa52d74496a2cef4000e587600"></a><a name="l8ea2b7aa52d74496a2cef4000e587600"></a>During a series of insertions into an existing GIN index that has <strong id="EN-US_TOPIC_0000001145510811__b842352706153243">fastupdate</strong> enabled, the system will clean up the pending-entry list whenever the list grows larger than <strong id="EN-US_TOPIC_0000001145510811__b842352706153239">work_mem</strong>. To avoid fluctuations in observed response time, it is desirable to have pending-list cleanup occur in the background (that is, via autovacuum). Foreground cleanup operations can be avoided by increasing <strong id="EN-US_TOPIC_0000001145510811__b842352706153342">work_mem</strong> or making <strong id="EN-US_TOPIC_0000001145510811__b842352706153344">autovacuum</strong> more aggressive. However, if <strong id="EN-US_TOPIC_0000001145510811__b9713131795717">work_mem</strong> is increased, a foreground cleanup (if any) will take a longer time.</p>
|
|
</li><li id="EN-US_TOPIC_0000001145510811__l6b54cc5f7f38435c9b20696d1d56ad68">gin_fuzzy_search_limit<p id="EN-US_TOPIC_0000001145510811__a25abaf46663c4ec99d92e1b60f3b10bf"><a name="EN-US_TOPIC_0000001145510811__l6b54cc5f7f38435c9b20696d1d56ad68"></a><a name="l6b54cc5f7f38435c9b20696d1d56ad68"></a>The primary goal of developing GIN indexes is to create support for highly scalable full-text search in <span id="EN-US_TOPIC_0000001145510811__text343042565">GaussDB(DWS)</span>. However, a very large set of results may be returned by a full-text query for words that frequently occur. In addition, reading many tuples from the disk and sorting them will consume large numbers of resources, which is unacceptable for production.</p>
|
|
<p id="EN-US_TOPIC_0000001145510811__a61c4e4b846614e4fb771601f79c152dd">To facilitate controlled execution of such queries, GIN has a configurable soft upper limit on the number of rows returned: the <strong id="EN-US_TOPIC_0000001145510811__en-us_topic_0085032370_b842352706102848">gin_fuzzy_search_limit</strong> configuration parameter. It is set to 0 (meaning no limit) by default. If a non-zero limit is set, then the returned set is a subset of the whole result set, chosen at random.</p>
|
|
</li></ul>
|
|
</div>
|
|
<div>
|
|
<div class="familylinks">
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="dws_06_0270.html">GIN Indexes</a></div>
|
|
</div>
|
|
</div>
|
|
|