public inbox for [email protected]  

help / color / mirror / Atom feed

From: Imseih (AWS), Sami <[email protected]>
To: Bossart, Nathan <[email protected]>
To: Masahiko Sawada <[email protected]>
Cc: Justin Pryzby <[email protected]>
Cc: Peter Geoghegan <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: Add index scan progress to pg_stat_progress_vacuum
Date: Thu, 13 Jan 2022 03:52:46 +0000
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<CAH2-Wzmz4Z+UYqRgYHuyxYHha4Gn-aBprydmG0n+m6J2J_ABSA@mail.gmail.com>
	<CAD21AoCKOFjU8XpPjXgfNrP3-V71AL5NKY+3or7eeRnNMKqi0g@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAD21AoCWFyvtf_EHHLWqejDjW0=apRugn_=UkpGzY5OgKhkH2g@mail.gmail.com>
	<[email protected]>

On 1/12/22, 1:28 PM, "Bossart, Nathan" <[email protected]> wrote:

    On 1/11/22, 11:46 PM, "Masahiko Sawada" <[email protected]> wrote:
    > Regarding the new pg_stat_progress_vacuum_index view, why do we need
    > to have a separate view? Users will have to check two views. If this
    > view is expected to be used together with and joined to
    > pg_stat_progress_vacuum, why don't we provide one view that has full
    > information from the beginning? Especially, I think it's not useful
    > that the total number of indexes to vacuum (num_indexes_to_vacuum
    > column) and the current number of indexes that have been vacuumed
    > (index_ordinal_position column) are shown in separate views.

 > I suppose we could add all of the new columns to
 > pg_stat_progress_vacuum and just set columns to NULL as appropriate.
 > But is that really better than having a separate view?

To add, since a vacuum can utilize parallel worker processes + the main vacuum process to perform index vacuuming, it made sense to separate the backends doing index vacuum/cleanup in a separate view. 
Besides what Nathan suggested, the only other clean option I can think of is to perhaps create a json column in pg_stat_progress_vacuum which will include all the new fields. My concern with this approach is that it will make usability, to flatten the json, difficult for users.

    > Also, I’m not sure how useful index_tuples_removed is; what can we
    > infer from this value (without a total number)?

>    I think the idea was that you can compare it against max_dead_tuples
>   and num_dead_tuples to get an estimate of the current cycle progress.
>    Otherwise, it just shows that progress is being made.

The main purpose is to really show that the "index vacuum" phase is actually making progress. Note that for certain types of indexes, i.e. GIN/GIST the number of tuples_removed will end up exceeding the number of num_dead_tuples.

    Nathan

    [0] https://postgr.es/m/7874FB21-FAA5-49BD-8386-2866552656C7%40amazon.com

view thread (74+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Add index scan progress to pg_stat_progress_vacuum
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox