Re: New vacuum option to do only freezing

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: "Bossart, Nathan" <bossartn(at)amazon(dot)com>
Cc: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: New vacuum option to do only freezing
Date: 2019-02-02 16:04:55
Message-ID: 201902021604.zimvqvgmo672@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-02-02 16:29:10 Refactoring IndexPath representation of index conditions
Previous Message Masahiko Sawada 2019-02-02 15:07:53 Re: [HACKERS] Block level parallel vacuum