Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sKLEx-009e8A-Q7 for pgsql-general@arkaria.postgresql.org; Thu, 20 Jun 2024 17:06:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sKLEv-00BZYX-F2 for pgsql-general@arkaria.postgresql.org; Thu, 20 Jun 2024 17:06:26 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sKLEu-00BZXW-4K for pgsql-general@lists.postgresql.org; Thu, 20 Jun 2024 17:06:26 +0000 Received: from fout1-smtp.messagingengine.com ([103.168.172.144]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sKLEr-002gHm-4P for pgsql-general@postgresql.org; Thu, 20 Jun 2024 17:06:24 +0000 Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailfout.nyi.internal (Postfix) with ESMTP id B70E31380195; Thu, 20 Jun 2024 13:06:18 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 20 Jun 2024 13:06:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aklaver.com; h= cc:content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1718903178; x=1718989578; bh=IR7l30UCTOvn6pW8nVi1G1dnCnNRILW5oJqNKgwm5u8=; b= CAgWFhTKKH8wFb2PdyByMk5wptFJZaACkjyR6wipOFCGgaGRDLZHpgwH3ET0IAE+ CcejK03Ojh1E1GGiYAK8LAX34taQPZJjR0pOGufhrJnJTsaUdtKCr2d0h3CldO1n KPluNdL856SeUYdKXxWU724MQC2hWWywU0nq0FfZQ/QD4XMVGXGJi4etMFmIWfGO 3mjkF+WcW/0Sq6cDfjdJxJPbsT/LFJ5k/dKk+DSocA5VkqGJndknctdeNi61bZO5 ERgv7dk9DnQUZZaDAZvl9bcVuabTF76U/ITq2+z5iEnpEXz2m2VH6tOcQC5yUDYB noFYJPHKg3SzZ/WWR9tEug== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1718903178; x= 1718989578; bh=IR7l30UCTOvn6pW8nVi1G1dnCnNRILW5oJqNKgwm5u8=; b=d FepJvR2hlSD8LcTZyaGm/4mXwA9j4fBTPqcXMSxLPWBIiefy3BGMWz5cYLyhWTp1 Mns5XKZZ6JDgmt6Sgq9OkLzaj25MUytfEzL7qOwE7S1srIZa2plsWWorpA+Y+L9x aItgCxSdTspljljPHNBgdNocZ4WZWnISq4vvNjoD6WCPxN7H+CGCeFKVVl/xBshB okZ4eNmjVOF8rvqUIPDg0aSCBmV0Fuv44pb5XoAekyjV9jPKc2vHfqJUbDuLwS33 lnylAhnHaBDS9ZgEze1ivUQyZkwRcoo5F7Dvd8mv4TUVdc1TfAwTGAZMsPFT15qt xQWHWKrGImUhTmcD/1eoQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfeefvddguddutdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfhfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeetughr ihgrnhcumfhlrghvvghruceorggurhhirghnrdhklhgrvhgvrhesrghklhgrvhgvrhdrtg homheqnecuggftrfgrthhtvghrnhepkeefheduvdejiefgieefjedtudduffelvdefleeh fedtieffuefgvdekleegtddvnecuffhomhgrihhnpehpohhsthhgrhgvshhqlhdrohhrgh enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrughr ihgrnhdrkhhlrghvvghrsegrkhhlrghvvghrrdgtohhm X-ME-Proxy: Feedback-ID: i76984098:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 20 Jun 2024 13:06:17 -0400 (EDT) Message-ID: <3637977d-554d-4ebe-a8fc-3a4da49e5664@aklaver.com> Date: Thu, 20 Jun 2024 10:06:16 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Autovacuum, dead tuples and bloat To: "Shenavai, Manuel" , pgsql-general References: Content-Language: en-US From: Adrian Klaver In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 6/20/24 09:46, Shenavai, Manuel wrote: > Hi everyone, > > we can see in our database, that the DB is 200GB of size, with 99% > bloat. After vacuum full the DB decreases to 2GB. > > DB total size: 200GB > > DB bloat: 198 GB > > DB non-bloat: 2GB > > We further see, that during bulk updates (i.e. a long running > transaction), the DB is still growing, i.e. the size of the DB growth by > +20GB after the bulk updates. How soon after the updates did you measure the above? > > My assumption is, that after an autovacuum, the 99% bloat should be > available for usage again. But the DB size would stay at 200GB. In our > case, I would only expect a growth of the DB, if the bulk-updates exceed > the current DB size (i.e. 220 GB). Was the transaction completed(commit/rollback)? Are there other transactions using the table or tables? > > How could I verify my assumption? > > I think of two possibilities: > > 1. My assumption is wrong and for some reason the dead tuples are not > cleaned so that the space cannot be reused > 2. The bulk-update indeed exceeds the current DB size. (Then the growth > is expected). > > Can you help me to verify these assumptions? Are there any statistics > available that could help me with my verification? Use: https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-TABLES-VIEW Select the rows that cover the table or tables involved. Look at the vacuum/autovacuum/analyze fields. > > Thanks in advance & > > Best regards, > > Manuel > -- Adrian Klaver adrian.klaver@aklaver.com