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 1tiapw-0009l0-Ba for pgsql-general@arkaria.postgresql.org; Thu, 13 Feb 2025 15:09:08 +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 1tiapu-009JXm-DH for pgsql-general@arkaria.postgresql.org; Thu, 13 Feb 2025 15:09:07 +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 1tiapt-009JWm-UF for pgsql-general@lists.postgresql.org; Thu, 13 Feb 2025 15:09:06 +0000 Received: from mail-il1-x12d.google.com ([2607:f8b0:4864:20::12d]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tiapr-000bNr-1M for pgsql-general@lists.postgresql.org; Thu, 13 Feb 2025 15:09:05 +0000 Received: by mail-il1-x12d.google.com with SMTP id e9e14a558f8ab-3ce7c4115e8so6805475ab.1 for ; Thu, 13 Feb 2025 07:09:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1739459343; x=1740064143; darn=lists.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=QzQn7vnNI1+2OlamrBhQB17h3R8ZG/cfeEQDqZvY57k=; b=F8ulXkZSSOF9dVWZaGCrBimNrWWC8YyDsixV5LE3oy8EWyIAyfRz8t7Xn5nPiZY2ct 9GewHQJ9ZM6JFbJIrjYPA9ywCK1aVWrpau1hJhi/G91pF+sp0SjEbJAZGOifKVGQu3s2 Fru1Anig2UYvYzzesb74JaUPXdZcSuNF3dzRMRmMOwqFZj12FK9U/a2NQkSB/zkOALAp tGDjI4IOZc7Iwvf/j+34zuqY5cVkM8WGCblpF6VhcakJmHUAlGKlXA4ubLN4Dz7cYMvC GI7JE/OqLELmlkQYoT9vb/jKrAnvGdkdMXIVDxrgWUtOacigtif2sMOX7paRAY8POAIs wRDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739459343; x=1740064143; 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=QzQn7vnNI1+2OlamrBhQB17h3R8ZG/cfeEQDqZvY57k=; b=RqeUFV6JpK49hd5uRWeB+3M0ZNRmifISiSLZ5Fc0RekqzZaQs4YZyCpjHt7zXc1vBF 4vpGR7Q5ZG8gApdtTuyqwBen+Pzkqm4DNn8yDTk4X+5Gs8NFsErV76TAA7jAtn65TOWb IlGV3BQ8Qv+9kIXLjxK/1KsMlM8gVdMbg6xmIPDNHmOt6SbJYRsdG+NzGZsfAnLX2GEK Ny83QxhC3J0rfDzb+YjKZowAoXPkKRSgufQWfgfhje8472qJyXWx7fHCo54mtXVptga3 SCMksjQJeKWVJUt6b7TUH5M767KZt/E2wbb0i851n2sdxXQLo/6MbdukdPN+EzFwTuBa H1FQ== X-Forwarded-Encrypted: i=1; AJvYcCUIFv4/5FWfIhq7JFaFg3h/yEvXXzpdAK4/eB4g77iGISiKkYavO66tVlEvLdLAz3aSa9z5DNzVYtoNuyHb@lists.postgresql.org X-Gm-Message-State: AOJu0YxCz5zROqQJGVdGcUllX34ZbEqJKVfMPx8C56Rb20OVH2NJ9H/Z UV1FDV1aQZf/2AfeTaAgjj0wtSmmrxYDIzut8v1dg302/4dmAtz7zRCmENIULMnycqgD69LXYvZ XLNBA2/IVtoUhmZmp+XPx35+qC+61xA== X-Gm-Gg: ASbGncvpig+hEEoLWs3HxaGByqjXoNr5xC7tcRiDOzV9IKi9NzttEP1LM11hqEs9Lyx Xil0few8qYB2X6124EpFCrtsSFougJHSRuBwzNdpcF0cgSvdk/tSAyoRx4NI8gaca6WP4tW6nRC 9s0Je38wJMTOX2Dg84aYAvaRXeQCeyRh0= X-Google-Smtp-Source: AGHT+IGbUVwimp1vSwRU5AWMYqdlNzm6bDlsKf5wWZDOZv2jtTH7AHuF9OdgS5Kf9h6hELiHv1OM0LlbxR/Ri+GEKCY= X-Received: by 2002:a05:6e02:470e:b0:3d1:5f26:121 with SMTP id e9e14a558f8ab-3d18cd1682amr24770675ab.9.1739459342468; Thu, 13 Feb 2025 07:09:02 -0800 (PST) MIME-Version: 1.0 References: <8ac6a1dd-db82-4ea7-8186-0c354d79049f@aklaver.com> <9fa75099-1ee9-43de-ac6e-945841b184eb@aklaver.com> <22406cdf-83f5-4b98-b07e-7827afe97f93@aklaver.com> In-Reply-To: From: Greg Sabino Mullane Date: Thu, 13 Feb 2025 10:08:27 -0500 X-Gm-Features: AWEUYZn79P-sv2ooqaoYvXmRke_TRnsFDapPPYHjD7Cp8XWTcfNedqi83dvA4vc Message-ID: Subject: Re: Best Approach for Swapping a Table with its Copy To: Marcelo Fernandes Cc: Adrian Klaver , pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000359042062e077000" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000359042062e077000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 12, 2025 at 9:02=E2=80=AFPM Marcelo Fernandes wrote: > What I am after is the same, but I seek a deeper understanding of what it > does, and why it does it. For example, it swaps relfilenode. Why? It is surgically replacing all pointers to the old data with pointers to the new data. Yes, with lots of system catalog shenanigans. pg_repack is meant to do what vacuum full does, but in a faster way. Imagine your table is an 18-wheeler truck, with a cab (system catalog stuff) and a trailer (full of data). We don't want a whole new truck, we want to change out the trailer. With VACUUM FULL, you stop all traffic while you pull the truck to the side of the road and turn it off. A new truck is pulled alongside it, and everything from the old trailer is unloaded and placed in the new one. The new trailer is hooked to the cab, and pulls away into the now-moving traffic. With pg_repack, you keep driving full speed. A new truck pulls up alongside your truck, and the new trailer is filled based on the old one. At the last moment, all the wires are pulled from the old trailer and hooked to the new trailer. The old trailer is detached and left to crash into the mutant bikers who have been pursuing you. It's the same cab, but the trailer (e.g. relfilenodes) has been changed. It's technically possible to do something similar for your use case, but it's not trivial. All the cab to trailer wires must be precisely changed. Everything directly related to the data must be swapped: heap, indexes, toast. Cheers, Greg -- Crunchy Data - https://www.crunchydata.com Enterprise Postgres Software Products & Tech Support --000000000000359042062e077000 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Feb 12, 2025 at 9:02=E2=80=AFPM M= arcelo Fernandes <marcefern7@gma= il.com> wrote:
What I am after is the s= ame, but I seek a deeper understanding of what it does, and why it does it.= For example, it swaps relfilenode. Why?

It= is surgically replacing all pointers to the old data with pointers to the = new data. Yes, with lots of system catalog shenanigans.=C2=A0
pg_repack is meant to do what vacuum full does, but in a faster= way. Imagine your table is an 18-wheeler truck, with a cab (system catalog= stuff) and a trailer (full of data). We don't want a whole new truck, = we want to change out the trailer.

With VACUUM FUL= L, you stop all traffic while you pull the truck to the side of the road an= d turn it off. A new truck is pulled alongside it, and everything from the = old trailer is unloaded and placed in the new one. The new trailer is hooke= d to the cab, and pulls away into the now-moving traffic.

With pg_repack, you keep driving full speed. A new truck pulls up a= longside your truck, and the new trailer is filled based on the old one. At= the last moment, all the=C2=A0wires are pulled from the old trailer and ho= oked to the new trailer. The old trailer is detached and left to crash into= the mutant bikers who have been pursuing you. It's the same cab, but t= he trailer (e.g. relfilenodes) has been changed.

I= t's technically possible to do something similar for your use case, but= it's not trivial. All the cab to trailer wires must be precisely chang= ed. Everything directly related to the data must be swapped: heap, indexes,= toast.

Cheers,
Greg

--<= /div>
Enterprise Postgres Softw= are Products & Tech Support

--000000000000359042062e077000--