Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lDTL6-0000eq-Ai for pgsql-admin@arkaria.postgresql.org; Sat, 20 Feb 2021 14:34:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lDTL2-0005al-Ei for pgsql-admin@arkaria.postgresql.org; Sat, 20 Feb 2021 14:34:28 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lDTL2-0005ae-0o for pgsql-admin@lists.postgresql.org; Sat, 20 Feb 2021 14:34:28 +0000 Received: from admin.sibptus.ru ([2001:19f0:5001:21dc::10]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lDTKx-0004WW-4T for pgsql-admin@lists.postgresql.org; Sat, 20 Feb 2021 14:34:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sibptus.ru; s=20181118; h=In-Reply-To:Message-ID:Subject:To:From:Date; bh=SCU5PE3JVKRiITZ5uC/IKV2zD6/Ss6oKucS8kD3Q/Bw=; b=jh00OAJ2nW+h1nlydyJj95TPGQ ysIabuoBuq0kd2izE7e8eK/o2eD0Zsk+8vc9Rnyo+7S8iRpC3TjbawggJ0kkD1MdFlseM2KTxFZfc oWnQKFjh+bG89ZvoFcpPswmbyUczMuzJqPLR59cDgwjZn6VtaIwTs0lpD2zQDV1FdIOE=; Received: from vas by admin.sibptus.ru with local (Exim 4.94 (FreeBSD)) (envelope-from ) id 1lDTKu-0005vC-2L for pgsql-admin@lists.postgresql.org; Sat, 20 Feb 2021 21:34:20 +0700 Date: Sat, 20 Feb 2021 21:34:20 +0700 From: Victor Sudakov To: pgsql-admin@lists.postgresql.org Subject: Re: index bloat estimation Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Key: http://admin.sibptus.ru/~vas/ X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Keith Fiske wrote: > > > Actually this could still be an issue, but all really depends on the size > of the tables involved. Long running transactions on the replica have the > potential to either delay replication entirely > (max_standby_archive_delay, max_standby_streaming_delay) or cause more > bloat than normal on the primary (hot_standby_feedback). The latter is more As I said earlier, if you have a dedicated replica for OLAP running continuous recovery from a WAL archive (not from a replication slot), this is not an issue. You can do whatever you want with this replica: stop it, make it a delayed replica, it cannot affect the master in any way. > > The approximate/quick mode of pgstattuple could certainly help with this > problem, but as the issue you opened up on the github repo pointed out, > that skips over scanning toast tables ( > https://github.com/keithf4/pg_bloat_check/issues/22) and also does not work > against indexes which are more often the problem with bloat and query > performance. I have seen significant bloat forming in the toast tables > (hundreds of GB) when the regular table only reports very minimal bloat. So > I don't recommend relying completely on the approximate check. I'll mind that, thank you. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/