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 1sHfW6-009xOM-CR for pgsql-general@arkaria.postgresql.org; Thu, 13 Jun 2024 08:09:06 +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 1sHfW4-00FLtt-6n for pgsql-general@arkaria.postgresql.org; Thu, 13 Jun 2024 08:09:05 +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 1sHfW3-00FLtl-SG for pgsql-general@lists.postgresql.org; Thu, 13 Jun 2024 08:09:04 +0000 Received: from mail-ua1-x936.google.com ([2607:f8b0:4864:20::936]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sHfW2-001R20-6l for pgsql-general@postgresql.org; Thu, 13 Jun 2024 08:09:04 +0000 Received: by mail-ua1-x936.google.com with SMTP id a1e0cc1a2514c-80b8d0d19e8so197815241.1 for ; Thu, 13 Jun 2024 01:09:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718266141; x=1718870941; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=U/8RH/BlDfRZP3omkdCtvt/wxhRHpcD+1yeMIyobXvY=; b=Bjfh3bKabqqAXn592XEsZrnVBNjMKXsoLQ0FxlnYV+LlkfBmqju8uE+OZU/ochF0CB XBI0OpDGsaAGFPKKij2N1ZStU+DR5xX/8sRTHJkHj4M4XNkpsQMyhy+BqnDTEuISm043 dsMh1HH3+2Mz7sEnDeFC4JMG7VB2mMByH7T6Ko+9FEGs2tk3h9LL80dU3soRaXCXdF/6 6LKRydbeASzq1JBcXY/ZVs4HCZl2lbUFxFfAcRDQJXVP/GzDKFcpNvo1trWu+t5ye1LN oYgH7LlWQ53ymAZwR1q2ev05c8JHPpEGEHPvExKbtuLyGKpZkFSDaByLDI153yQVcFej alvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718266141; x=1718870941; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=U/8RH/BlDfRZP3omkdCtvt/wxhRHpcD+1yeMIyobXvY=; b=jLcY8ZBrp84+0Atoth7am9vQpcQrByQO694G37vjFDx2cJ8Dnu6OXKOrsUJ3w28e7e HwbLtaaSYIFeiL3RPtB+iAhUXHaycmfKB//TdYe3io7pXEizt+hRss/r6C/Ja4S4sS5/ U1gKyGmZGB8OZs/Y3w1+46vvOTldhyKBqZwCMVQ81jltPD+cxR/9dgJ92fvT9cQQYmob W3gEPyxfFepnxYegoZQWSqPxFUriovPopKd9moUuGxM8ck9P5EZ9o0MQTo9vQVdann/o D5I6spM2tvOYSJMsTkQFt0UINZIbi26D3+EdUX3HfNpwSCfSdpomw72v+kdmaKd/aDBJ weTw== X-Gm-Message-State: AOJu0YxSVQ7imzOrpMwMoqCeq2loIQPK4g5nAfP1B6AoQ4Dyr58BuT5r 4tvrkLlXW8KADQpLLFtTdOhY872a1u4QdskZRYBvHwc5L1lyFDbQvaFtOLpobkXEEcEzd92J0As 27wRoSUrIW+8Q3kFZoPgE4Mmf7mY= X-Google-Smtp-Source: AGHT+IFV1r2oS6EflDdU8u4tmvMB/5CFKOu2WzqPPBCdxgdRiOeyqcSJ0Fgv6zGMfs/4J0y1D3j3fahc6tCF/Obw2OI= X-Received: by 2002:a05:6102:26cb:b0:48d:a8da:2c00 with SMTP id ada2fe7eead31-48da8da35b9mr285091137.32.1718266140567; Thu, 13 Jun 2024 01:09:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kashif Zeeshan Date: Thu, 13 Jun 2024 13:08:49 +0500 Message-ID: Subject: Re: TOAST Table / Dead Tuples / Free Pages To: "Shenavai, Manuel" Cc: pgsql-general Content-Type: multipart/alternative; boundary="000000000000f03105061ac102f3" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000f03105061ac102f3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. 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=E2=80=AFPM 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=E2=80=99t want to use VACUUM FULL du= e to the > exclusive lock. > > > > Is there any way to remove the dead tuples and free the pages? > > > > Thanks in advance & > > Best regards, > > Manuel > > > --000000000000f03105061ac102f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

You can use the CLUSTER c= ommand, which will physically reorder the table based on index, effectively= reducing the size of the table without using VACUUM.

<= div>CLUSTER your_table USING your_index;

Or you ca= n use the pg_repack extension as well.

pg_repack -= d your_database -t your_table

Regards
Kashif Zeeshan



On Thu, Jun 13, 202= 4 at 12:55=E2=80=AFPM Shenavai, Manuel <manuel.shenavai@sap.com> wrote:

Hi everyone,

=C2=A0

I created a simple scenario to = understand the handling of TOASTs: There is an empty database with a single table an= d record. The single record gets updated multiple times with 10MB (bytea co= lumn). I can see that the table/toasttable size is growing (500MB).

=C2=A0

Now I tried to find a way to ge= t the DB size down again (it should be around 10MB instead of 500MB). I don= =E2=80=99t want to use VACUUM FULL due to the exclusive lock.=

=C2=A0

Is there any way to remove the = dead tuples and free the pages?

=C2=A0

Thanks in advance &<= u>

Best regards,

Manuel

=C2=A0

--000000000000f03105061ac102f3--