Horton

Re: error context for vacuum to include block number

Justin Pryzby <pryzby@telsasoft.com>

View thread View on postgr.es
From: Justin Pryzby <pryzby@telsasoft.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, Andres Freund <andres@anarazel.de>, pgsql-hackers@postgresql.org
Date: 2019-12-15T16:27:12Z
Lists: pgsql-hackers 
On Sun, Dec 15, 2019 at 10:07:08PM +0900, Michael Paquier wrote:
> On Fri, Dec 13, 2019 at 04:47:35PM -0600, Justin Pryzby wrote:
> > It's related code which I cleaned up before adding new stuff.  Not essential,
> > thus separate (0002 should be backpatched).
> 
> The issue just causes some extra work and that's not a bug, so applied
> without a backpatch.

Thanks

> For 0003, I think that lazy_vacuum_heap_index() can be confusing as
> those indexes are unrelated to heap.  Why not naming it just
> lazy_vacuum_all_indexes()?  The routine should also have a header
> describing it.

I named it so because it calls both lazy_vacuum_index
("PROGRESS_VACUUM_PHASE_VACUUM_INDEX") and
lazy_vacuum_heap("PROGRESS_VACUUM_PHASE_VACUUM_HEAP")

I suppose you don't think the other way around is better?
lazy_vacuum_index_heap

Justin

Commits

  1. Avoid calls to RelationGetRelationName() and RelationGetNamespace() in

  2. Introduce vacuum errcontext to display additional information.

  3. Fix mesurement of elapsed time during truncating heap in VACUUM.

  4. Allow vacuum command to process indexes in parallel.

  5. Refactor code dedicated to index vacuuming in vacuumlazy.c

  6. Remove duplicated progress reporting during heap scan of VACUUM