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 1sHlad-00AdNj-ES for pgsql-general@arkaria.postgresql.org; Thu, 13 Jun 2024 14:38:11 +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 1sHlab-002KJx-2V for pgsql-general@arkaria.postgresql.org; Thu, 13 Jun 2024 14:38:09 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sHlaa-002KJp-7F for pgsql-general@lists.postgresql.org; Thu, 13 Jun 2024 14:38:09 +0000 Received: from wfhigh6-smtp.messagingengine.com ([64.147.123.157]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sHlaY-0018Ka-1t for pgsql-general@postgresql.org; Thu, 13 Jun 2024 14:38:07 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailfhigh.west.internal (Postfix) with ESMTP id A9A321800098; Thu, 13 Jun 2024 10:38:03 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 13 Jun 2024 10:38:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aklaver.com; h= cc: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=fm3; t=1718289483; x=1718375883; bh=wLEJC6FTf+xsXR6uMhvWrt3Gk0jeEDlMwFMtpC6+7gk=; b= Jdn6qVXhPs80Zy5mvjlxPgIe1xxz3Xecpu8oid+SpFEicENREVH1ZcIF1HQus6E3 CMlS9ovEJGBTIEl3e6hXWI25xjXH92UoRxRN5udcoJ1PdE6JFMW86VPR0hPPqwn0 T6HLG46o9zQeJfdyVZictXlWv3pYzWk7qK8MRchnDGBaF+A7vN6+gnk4ei3OiKNe QqzPihLx4oW8d5NsACpGRnzN0CCAtuHV7+LHag0Zg7Uow/pXe6hnNO+FaVRb6NaI ofb4LgTzrombOzaL1Y4tckfhTjsSbid6EargTvkXVuYUT9bUcjFaZKjr3yeLPcL9 nVAM19nELeuU2rdHNuIJLg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm1; t=1718289483; x= 1718375883; bh=wLEJC6FTf+xsXR6uMhvWrt3Gk0jeEDlMwFMtpC6+7gk=; b=K xvEAPHRKfYgOAcKNTbq2GuCKIxOKinwH6mnJXxXLixj1mZ425hGdkDK/GobOmO2G dDPRrNo7vlTsRWXdvJXo/99ijApUa28ujoMmV2WKLKXh2a9lqoCu+si5pYBuBeah SjPOTdrDkztZAwUSLvpPuuuD0G5mJ0pfal0wWo+hm2jlYG1Yaw65qKIKW1UhO/RN BpFQDFm9T9mgTr2vbNtvshp0udaOgIeuiYblSp/V5gj+xsn0eCsiz//boFqwkvH7 5H96FNnn6WWhN3yUCQ05+4blSgCyd8B6UqYwlouPBgeLnIbpTLOJtDyJr0Ja5LZE k0/p7UzRGVmCkCRYhAaMg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrfedujedgjeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdejnecuhfhrohhmpeetughr ihgrnhcumfhlrghvvghruceorggurhhirghnrdhklhgrvhgvrhesrghklhgrvhgvrhdrtg homheqnecuggftrfgrthhtvghrnhepgfdufeekhfevfeelveeiueevhedvuddukeduvddv lefhueeuieejtdeuvdevvdeunecuffhomhgrihhnpehpohhsthhgrhgvshhqlhdrohhrgh enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrughr ihgrnhdrkhhlrghvvghrsegrkhhlrghvvghrrdgtohhm X-ME-Proxy: Feedback-ID: i76984098:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 13 Jun 2024 10:38:02 -0400 (EDT) Message-ID: <28102d69-6305-4014-a572-8a29f5a19710@aklaver.com> Date: Thu, 13 Jun 2024 07:38:01 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: TOAST Table / Dead Tuples / Free Pages To: Kashif Zeeshan , "Shenavai, Manuel" Cc: 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: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 6/13/24 01:08, Kashif Zeeshan wrote: > Hi > > You can use the CLUSTER command, which will physically reorder the table > based on index, effectively reducing the size of the table without using > VACUUM. From OP: "I don’t want to use VACUUM FULL due to the exclusive lock." From here https://www.postgresql.org/docs/current/sql-cluster.html "When a table is being clustered, an ACCESS EXCLUSIVE lock is acquired on it. This prevents any other database operations (both reads and writes) from operating on the table until the CLUSTER is finished." > > CLUSTER your_table USING your_index; > > Or you can use the pg_repack extension as well. > > pg_repack -d your_database -t your_table > > Regards > Kashif Zeeshan > > > > On Thu, Jun 13, 2024 at 12:55 PM Shenavai, Manuel > > wrote: > > Hi everyone,____ > > __ __ > > I created a simple scenario to understand the handling of TOASTs > : There > is an empty database with a single table and record. The single > record gets updated multiple times with 10MB (bytea column). I can > see that the table/toasttable size is growing (500MB).____ > > __ __ > > Now I tried to find a way to get the DB size down again (it should > be around 10MB instead of 500MB). I don’t want to use VACUUM FULL > due to the exclusive lock.____ > > __ __ > > Is there any way to remove the dead tuples and free the pages?____ > > __ __ > > Thanks in advance &____ > > Best regards,____ > > Manuel____ > > __ __ > -- Adrian Klaver adrian.klaver@aklaver.com