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 1sEdhz-002gSc-2c for pgsql-general@arkaria.postgresql.org; Tue, 04 Jun 2024 23:36:52 +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 1sEdhy-003HEZ-TZ for pgsql-general@arkaria.postgresql.org; Tue, 04 Jun 2024 23:36:50 +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 1sEdhy-003HER-IK for pgsql-general@lists.postgresql.org; Tue, 04 Jun 2024 23:36:50 +0000 Received: from mail-oa1-x30.google.com ([2001:4860:4864:20::30]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sEdhw-0001tp-6Q for pgsql-general@postgresql.org; Tue, 04 Jun 2024 23:36:49 +0000 Received: by mail-oa1-x30.google.com with SMTP id 586e51a60fabf-25075eeb9f6so889556fac.2 for ; Tue, 04 Jun 2024 16:36:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717544206; x=1718149006; darn=postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=Qebz+ZsLIpfkhHF/rt0DCrTUR1/qR14QCYZXrlHuL6w=; b=O4w0HRFnYyaYP9S6oYLS4WaFzXUrQ8jxgfHoxn8FPpc1tS2TyFquTOiDDH4NO4Pr+D pAcxUF+2qndyzjuOOwmHbY0PgeACudkxo64k9rmiIrevUXOnxv2sQnbRJOHKj1c9M1/p dTEeN+9kVtTPkwtoJVCPLrNp6m+RTpzKGTnTxIIZfYEm7wxP3xaYCx/RlQdkzYqWjpTl ugPUteomliQt2iHajnHFX5VT/GPfICDVpMlOSb7RNiGiaV9EpMXHYibXQnq7hDUI8MuR NvhaLGjK97AQCgMBGhDPKzRwI9LZfpfd3wv1qZp5BbcZIcBFcFIq+pgQomDYayRkSHOc KnhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717544206; x=1718149006; h=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=Qebz+ZsLIpfkhHF/rt0DCrTUR1/qR14QCYZXrlHuL6w=; b=IuaMnEO9U3Frz+fYHf9hKHN1bhKvmJvLu4fioNv9prPOAgpwLaLPk9btaVYj1cE5gC CKYIZ9PvqxgUEbesF3Uadpvc627aTbU4eBObzDKwbiFuek+CNNgSB1ZA4daiuZ27kmAO s+jcIYkt/ll5FLvwZz9MbujpWZeKHMstItDPGBcGSRuorvx7mAkjHar2OY8NbOhfTnKH /YyKCe/CivWsocdPyIHOrSOIuHBnqyszlJdjqe2+TpCGALeEyaYoZx1mRU1sw8jmejBT lkd2Qb05oE9wFaCRGjGeAa/o/IvKE/ZQagFMspRvIL5Qm7WytrEwjhm3w0itSkn9m+oS 7tSQ== X-Gm-Message-State: AOJu0YwrSJXVKSmUieCFmvGTT86ODvkvMEoYvBmG7qn3dBDiq7BgVVcY jtRVveslNXJYsVvla/sx5CaKSVgHfMSjqYmguqpkl7d/ak+ZJeps8GbOyioeWyPL9hsOmdoHJEv WtBjskVLA2D9WfiHLHiyu2rIvnI1BcQ== X-Google-Smtp-Source: AGHT+IFTES0XQpl7+Kuha3bH/cyqUvHGS7zWjvEKeCXIohqJ1K+uY+y4jlkLVShzo/XkN5zyc2ajbfL1W2SmbYhs4Ik= X-Received: by 2002:a05:6870:a10c:b0:250:6e6c:b1f0 with SMTP id 586e51a60fabf-25122005780mr1315175fac.37.1717544205785; Tue, 04 Jun 2024 16:36:45 -0700 (PDT) MIME-Version: 1.0 References: <25e9749c-ff38-4832-9b26-386cac33b3d8@aklaver.com> <7005ac8c-2f83-4122-9172-04bca268f987@aklaver.com> <4b28e899-d802-43ce-b20b-655a9077f08f@gmail.com> In-Reply-To: From: Ron Johnson Date: Tue, 4 Jun 2024 19:36:34 -0400 Message-ID: Subject: Re: Purpose of pg_dump tar archive format? To: pgsql-general Content-Type: multipart/alternative; boundary="00000000000045a414061a18ec11" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000045a414061a18ec11 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 4, 2024 at 3:47=E2=80=AFPM Gavin Roy wrote: > > On Tue, Jun 4, 2024 at 3:15=E2=80=AFPM Ron Johnson > wrote: > >> >> But why tar instead of custom? That was part of my original question. >> > > I've found it pretty useful for programmatically accessing data in a dump > for large databases outside of the normal pg_dump/pg_restore workflow. Yo= u > don't have to seek through one large binary file to get to the data secti= on > to get at the data. > Interesting. Please explain, though, since a big tarball _is_ "one large binary file" that you have to sequentially scan. (I don't know the internal structure of custom format files, and whether they have file pointers to each table.) Is it because you need individual .dat "COPY" files for something other than loading into PG tables (since pg_restore --table=3Dxxxx does that, too= ), and directory format archives can be inconvenient? --00000000000045a414061a18ec11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jun 4, 2024 at 3:47=E2=80=AFPM Ga= vin Roy <gavinr@aweber.com> = wrote:

On Tue, Jun 4, 2024 at = 3:15=E2=80=AFPM Ron Johnson <ronljohnsonjr@gmail.com> wrote:
=
But why tar instead of custom? Th= at was part of my original question.

I've found it pretty useful for programmatically accessing= data in a dump for large databases outside of the normal pg_dump/pg_restor= e workflow. You don't have to seek through one large binary file to get= to the data section to get at the data.

Interesting.=C2=A0 Please explain, though, since a big tarball _is_= "one large binary file" that you have to sequentially scan.=C2= =A0 (I don't know the internal structure of custom format files, and wh= ether they have file pointers to each=C2=A0table.)

Is it because you need individual .dat=C2=A0"COPY" files for som= ething other than loading into PG tables (since pg_restore --table=3Dxxxx d= oes that, too), and directory format archives can be inconvenient?

--00000000000045a414061a18ec11--