Re: [HACKERS] GUC for cleanup indexes threshold.

On Mon, Feb 13, 2017 at 1:01 PM, Masahiko Sawada <sawada.mshk@gmail.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