</listitem>
</varlistentry>
- <varlistentry id="guc-pending-list-cleanup-size" xreflabel="pending_list_cleanup_size">
- <term><varname>pending_list_cleanup_size</varname> (<type>integer</type>)
+ <varlistentry id="guc-gin-pending-list-limit" xreflabel="gin_pending_list_limit">
+ <term><varname>gin_pending_list_limit</varname> (<type>integer</type>)
<indexterm>
- <primary><varname>pending_list_cleanup_size</> configuration parameter</primary>
+ <primary><varname>gin_pending_list_limit</> configuration parameter</primary>
</indexterm>
</term>
<listitem>
<acronym>GIN</> is capable of postponing much of this work by inserting
new tuples into a temporary, unsorted list of pending entries.
When the table is vacuumed, or if the pending list becomes larger than
- <xref linkend="guc-pending-list-cleanup-size">, the entries are moved to the
+ <xref linkend="guc-gin-pending-list-limit">, the entries are moved to the
main <acronym>GIN</acronym> data structure using the same bulk insert
techniques used during initial index creation. This greatly improves
<acronym>GIN</acronym> index update speed, even counting the additional
</varlistentry>
<varlistentry>
- <term><xref linkend="guc-pending-list-cleanup-size"></term>
+ <term><xref linkend="guc-gin-pending-list-limit"></term>
<listitem>
<para>
During a series of insertions into an existing <acronym>GIN</acronym>
index that has <literal>fastupdate</> enabled, the system will clean up
the pending-entry list whenever the list grows larger than
- <varname>pending_list_cleanup_size</>. To avoid fluctuations in observed
+ <varname>gin_pending_list_limit</>. To avoid fluctuations in observed
response time, it's desirable to have pending-list cleanup occur in the
background (i.e., via autovacuum). Foreground cleanup operations
- can be avoided by increasing <varname>pending_list_cleanup_size</>
+ can be avoided by increasing <varname>gin_pending_list_limit</>
or making autovacuum more aggressive.
However, enlarging the threshold of the cleanup operation means that
if a foreground cleanup does occur, it will take even longer.
</para>
<para>
- <varname>pending_list_cleanup_size</> can be overridden for individual
+ <varname>gin_pending_list_limit</> can be overridden for individual
GIN indexes by changing storage parameters, and which allows each
GIN index to have its own cleanup threshold.
For example, it's possible to increase the threshold only for the GIN
</variablelist>
<variablelist>
<varlistentry>
- <term><literal>pending_list_cleanup_size</></term>
+ <term><literal>gin_pending_list_limit</></term>
<listitem>
<para>
- Custom <xref linkend="guc-pending-list-cleanup-size"> parameter.
+ Custom <xref linkend="guc-gin-pending-list-limit"> parameter.
This value is specified in kilobytes.
</para>
</listitem>
},
{
{
- "pending_list_cleanup_size",
+ "gin_pending_list_limit",
"Maximum size of the pending list for this GIN index, in kilobytes.",
RELOPT_KIND_GIN
},
#include "utils/rel.h"
/* GUC parameter */
-int pending_list_cleanup_size = 0;
+int gin_pending_list_limit = 0;
#define GIN_PAGE_FREESIZE \
( BLCKSZ - MAXALIGN(SizeOfPageHeaderData) - MAXALIGN(sizeof(GinPageOpaqueData)) )
* call it when it can do all the work in a single collection cycle. In
* non-vacuum mode, it shouldn't require maintenance_work_mem, so fire it
* while pending list is still small enough to fit into
- * pending_list_cleanup_size.
+ * gin_pending_list_limit.
*
* ginInsertCleanup() should not be called inside our CRIT_SECTION.
*/
int numoptions;
static const relopt_parse_elt tab[] = {
{"fastupdate", RELOPT_TYPE_BOOL, offsetof(GinOptions, useFastUpdate)},
- {"pending_list_cleanup_size", RELOPT_TYPE_INT, offsetof(GinOptions,
+ {"gin_pending_list_limit", RELOPT_TYPE_INT, offsetof(GinOptions,
pendingListCleanupSize)}
};
},
{
- {"pending_list_cleanup_size", PGC_USERSET, CLIENT_CONN_STATEMENT,
+ {"gin_pending_list_limit", PGC_USERSET, CLIENT_CONN_STATEMENT,
gettext_noop("Sets the maximum size of the pending list for GIN index."),
NULL,
GUC_UNIT_KB
},
- &pending_list_cleanup_size,
+ &gin_pending_list_limit,
4096, 64, MAX_KILOBYTES,
NULL, NULL, NULL
},
#bytea_output = 'hex' # hex, escape
#xmlbinary = 'base64'
#xmloption = 'content'
-#pending_list_cleanup_size = 4MB
+#gin_pending_list_limit = 4MB
# - Locale and Formatting -
pg_strcasecmp(prev_wd, "(") == 0)
{
static const char *const list_INDEXOPTIONS[] =
- {"fillfactor", "fastupdate", "pending_list_cleanup_size", NULL};
+ {"fillfactor", "fastupdate", "gin_pending_list_limit", NULL};
COMPLETE_WITH_LIST(list_INDEXOPTIONS);
}
/* GUC parameters */
extern PGDLLIMPORT int GinFuzzySearchLimit;
-extern int pending_list_cleanup_size;
+extern int gin_pending_list_limit;
/* ginutil.c */
extern void ginGetStats(Relation index, GinStatsData *stats);
((relation)->rd_options && \
((GinOptions *) (relation)->rd_options)->pendingListCleanupSize != -1 ? \
((GinOptions *) (relation)->rd_options)->pendingListCleanupSize : \
- pending_list_cleanup_size)
+ gin_pending_list_limit)
/* Macros for buffer lock/unlock operations */
-- Test GIN index's reloptions
--
CREATE INDEX gin_relopts_test ON array_index_op_test USING gin (i)
- WITH (FASTUPDATE=on, PENDING_LIST_CLEANUP_SIZE=128);
+ WITH (FASTUPDATE=on, GIN_PENDING_LIST_LIMIT=128);
\d+ gin_relopts_test
Index "public.gin_relopts_test"
Column | Type | Definition | Storage
--------+---------+------------+---------
i | integer | i | plain
gin, for table "public.array_index_op_test"
-Options: fastupdate=on, pending_list_cleanup_size=128
+Options: fastupdate=on, gin_pending_list_limit=128
--
-- HASH
-- Test GIN index's reloptions
--
CREATE INDEX gin_relopts_test ON array_index_op_test USING gin (i)
- WITH (FASTUPDATE=on, PENDING_LIST_CLEANUP_SIZE=128);
+ WITH (FASTUPDATE=on, GIN_PENDING_LIST_LIMIT=128);
\d+ gin_relopts_test
--