On 2019-Feb-01, Bossart, Nathan wrote:
> IMHO we could document this feature at a slightly higher level without
> leaving out any really important user-facing behavior. Here's a quick
> attempt to show what I am thinking:
>
> With this option, VACUUM skips all index cleanup behavior and
> only marks tuples as "dead" without reclaiming the storage.
> While this can help reclaim transaction IDs faster to avoid
> transaction ID wraparound (see Section 24.1.5), it will not
> reduce bloat.
Hmm ... don't we compact out the storage for dead tuples? If we do (and
I think we should) then this wording is not entirely correct.
> Note that this option is ignored for tables
> that have no indexes. Also, this option cannot be used in
> conjunction with the FULL option, since FULL requires
> rewriting the table.
I would remove the "Also," in there, since it seems to me to give the
wrong impression about those two things being similar, but they're not:
one is convenient behavior, the other is a limitation.
> + /* Notify user that DISABLE_INDEX_CLEANUP option is ignored */
> + if (!vacrelstats->hasindex && (options & VACOPT_DISABLE_INDEX_CLEANUP))
> + ereport(NOTICE,
> + (errmsg("DISABLE_INDEX_CLEANUP is ignored
> because table \"%s\" does not have index",
> +
> RelationGetRelationName(onerel))));
>
> It might make more sense to emit this in lazy_scan_heap() where we
> determine the value of skip_index_vacuum.
Why do we need a NOTICE here? I think this case should be silent.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
