Date: Wed, 17 Feb 2021 09:27:24 +0700
From: Victor Sudakov <vas@sibptus.ru>
To: pgsql-admin@lists.postgresql.org
Subject: Re: index bloat estimation
Message-ID: <YCx/DJkZRw0mzRyr@admin.sibptus.ru>
References: <YCY7oPIXobbY8oPu@admin.sibptus.ru>
 <CAODZiv6YZj3GJsTv5_dp07VS2FACrFu_JPWsFVi64=1mJD_t0A@mail.gmail.com>
 <YCn8BmEe/4mA0KIb@admin.sibptus.ru>
 <CAODZiv5uVWASjuigUxJhmxmrQAdMoOxRu5vz97CkbuqH2-oxow@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAODZiv5uVWASjuigUxJhmxmrQAdMoOxRu5vz97CkbuqH2-oxow@mail.gmail.com>
Precedence: bulk

Keith Fiske wrote:

[dd]
> 
> You cannot run the actual scan on the replica, no. But it can be set to run
> against the replica and just report the statistics so you can have a cron
> set up to always run on the given system in case of failover. The
> "--recovery_mode_norun" can be set so it will only run if the target system
> is actually a primary.
> 
> I could possibly see about letting this actually run against the replica,
> however this can be a rather long running transaction depending on the size
> of the tables involved. You can set the "--commit_rate" to avoid some of
> that, but if you have really large tables, it can still run quite long. So
> this sort of check is really best run against the primary to avoid issues
> around having to allow long running queries on the replica (delayed
> replication or even worse bloat buildup).

If you have a dedicated replica for OLAP, even one running from a WAL
archive (not from a replication slot), this is not an issue.

So running pg_bloat_check against a replica would be very useful for
some of us.

-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/