Re: GUC for cleanup indexes threshold.

On Mon, Feb 13, 2017 at 1:01 PM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:

Thanks for the explanation. I've looked into the referred code. I'm
still in doubt. vacuumed_pages is incremented only when there are no
indexes, i.e. nindexes=0. Now, look at the following part in the
patch.

+ /*
+ * Do post-vacuum cleanup and statistics update for each index if
+ * the number of vacuumed page exceeds threshold.
+ */
+ cleanupidx_thresh = (float4) nblocks * vacuum_cleanup_index_scale;
+
+ elog(DEBUG3, "%s: vac: %d (threshold %0.f)",
+ RelationGetRelationName(onerel), nblocks, cleanupidx_thresh);
+ if (vacuumed_pages >= cleanupidx_thresh)
+ {
+ for (i = 0; i < nindexes; i++)
+ lazy_cleanup_index(Irel[i], indstats[i], vacrelstats);
+ }
So, unless vacuum_cleanup_index_scale_thresh is zero,
lazy_cleanup_index will never be called. IMO, this seems to be
incorrect. Besides, I've tested with non-zero(0.5)
vacuum_cleanup_index_scale_thresh and the regression tests for brin
and gin fails. (make installcheck)

+ {"vacuum_cleanup_index_scale_factor", PGC_USERSET,
CLIENT_CONN_STATEMENT,
+ gettext_noop("Number of pages containing dead tuple
prior to vacuum as a fraction of relpages."),
+ NULL
+ },
+ &vacuum_cleanup_index_scale,
+ 0.0, 0.0, 100.0,
+ NULL, NULL, NULL
+ },
Maximum value for vacuum_cleanup_index_scale_factor should be 1
instead of 100. As the code indicates, it is certainly not treated as
a percentage fraction of relpages.

--
Thanks & Regards,
Kuntal Ghosh
EnterpriseDB: http://www.enterprisedb.com