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 1sGkp7-00Glgw-MV for pgsql-hackers@arkaria.postgresql.org; Mon, 10 Jun 2024 19:36:58 +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 1sGkp5-00FQBY-Iu for pgsql-hackers@arkaria.postgresql.org; Mon, 10 Jun 2024 19:36:56 +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 1sGkp5-00FQBQ-8T for pgsql-hackers@lists.postgresql.org; Mon, 10 Jun 2024 19:36:56 +0000 Received: from mail-pg1-x530.google.com ([2607:f8b0:4864:20::530]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sGkp3-000g5v-EO for pgsql-hackers@postgresql.org; Mon, 10 Jun 2024 19:36:54 +0000 Received: by mail-pg1-x530.google.com with SMTP id 41be03b00d2f7-6ce533b643dso3677637a12.3 for ; Mon, 10 Jun 2024 12:36:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hagander.net; s=mail; t=1718048212; x=1718653012; 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=Vg6NE48+Y7rgjqhGrHlnH5/Ti+3G4nIqO2gHjuyYTqM=; b=V74bWiNjzFbkjSKqwM6R3MstVPqNdbzamnySeNEYe9QNPfx7h9/FuN22iip8Utmj1w cW+CCSlfKba5o6cenl8InLAq9pK2ig4kst7Bn6Xfc/yf6S/3vxIBtleZfW0LJmp0qUVr SleBhba7ZqnUh3csqxF45v3GK4CQC36yeZ5/ubSvLd+2dMKa85sywfQNctb3c1kwROt0 1Hx2Wsug9vw/jj4QFKd1JEanadtxx/pHmsTt9fVbqGUFjYr4RTt+RwwgwwXG02BJZbk6 HRZi8/bmCQdloZwXDx02ci+8dnEFmCq/Ou3PZn8c++whLVJ3Xy8UZjT8e0ZipwtX0PeC umhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718048212; x=1718653012; 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=Vg6NE48+Y7rgjqhGrHlnH5/Ti+3G4nIqO2gHjuyYTqM=; b=WaOXA9GMn331vgdMZX1I7L7/4wjWIrmCg8GNnHOzX1VxnXzNwtKckotRMshy7PfV9X gY+VUYlB+U1W+3BeFlSDBb+OWgM9M0A1ShCwL0AGrDuQKtam/HKFMhnA0HxRCHidO4ar Ks2e9v4qxwbry7ttq25MzcOgh3HHgwjt73yiKCjK9UpALrEyj/cc8nO/DekXwpXejlZh ZsAdgYO7+VbWubaSzF1oflds2JFl9vPJQXWVTlpLnJkGWSrXIbuP+F44K8tjfCMpxLxy muFzo8Hdm86routku8jdcFZq9ezceBVZ8IARxUZfn8/mH98MzSN9hIWR6mX0UtmPsxzb g81Q== X-Forwarded-Encrypted: i=1; AJvYcCUW6w8j1+F36YSewxM5bSOm/PqM8xF+x1HOLS+Ge4R8zQb+SMbwuku6+sQghfXjaEG9ZoaYAPx96E/mks7s0JfGS1WlbsoQSuUoWqYj X-Gm-Message-State: AOJu0YwjI7EAN3RdWt6RW9y2GFkg0OZNhhch3MQ85R0OhqadB7TkHi9Z zxxtat9BnYgkSWrUH+sTtHezq+ADQNTMwiU76DVh5VZfX0+SLb4nKeSEk1W5x8bTHYam3IHigb4 RU0SQ/XHw467t76dZMpR8WRu92QTRg6kYe/D0 X-Google-Smtp-Source: AGHT+IGZUY7E/m+LeHPp5BTG2MlMdmHYQWaB3YGQ5ZzlkvC+3dyQVa6eJO4MSRx5pfPGn4pMAIHm1/iI77YBfmq+Fs0= X-Received: by 2002:a17:90a:9907:b0:2bf:de8b:bef5 with SMTP id 98e67ed59e1d1-2c2bcad5a8amr9792458a91.12.1718048212139; Mon, 10 Jun 2024 12:36:52 -0700 (PDT) MIME-Version: 1.0 References: <740696.1718036463@sss.pgh.pa.us> In-Reply-To: <740696.1718036463@sss.pgh.pa.us> From: Magnus Hagander Date: Mon, 10 Jun 2024 21:36:37 +0200 Message-ID: Subject: Re: Non-text mode for pg_dumpall To: Tom Lane Cc: Nathan Bossart , Andrew Dunstan , PostgreSQL-development Content-Type: multipart/alternative; boundary="000000000000645a4f061a8e45cc" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000645a4f061a8e45cc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jun 10, 2024 at 6:21=E2=80=AFPM Tom Lane wrote: > Magnus Hagander writes: > > On Mon, Jun 10, 2024 at 5:03=E2=80=AFPM Nathan Bossart > > > wrote: > >> Is there a particular advantage to that approach as opposed to just > using > >> "directory" mode for everything? > > > A gazillion files to deal with? Much easier to work with individual > custom > > files if you're moving databases around and things like that. > > Much easier to monitor eg sizes/dates if you're using it for backups. > > You can always tar up the directory tree after-the-fact if you want > one file. Sure, that step's not parallelized, but I think we'd need > some non-parallelized copying to create such a file anyway. > That would require double the disk space. But you can also just run pg_dump manually on each database and a pg_dumpall -g like people are doing today -- I thought this whole thing was about making it more convenient :) --=20 Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/ --000000000000645a4f061a8e45cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jun 10, 2024 at 6:21=E2=80=AFPM T= om Lane <tgl@sss.pgh.pa.us> = wrote:
Magnus Hagander <magnus@hagander.net> writes:
> On Mon, Jun 10, 2024 at 5:03=E2=80=AFPM Nathan Bossart <nathandbossart@gmail.com= >
> wrote:
>> Is there a particular advantage to that approach as opposed to jus= t using
>> "directory" mode for everything?

> A gazillion files to deal with? Much easier to work with individual cu= stom
> files if you're moving databases around and things like that.
> Much easier to monitor eg sizes/dates if you're using it for backu= ps.

You can always tar up the directory tree after-the-fact if you want
one file.=C2=A0 Sure, that step's not parallelized, but I think we'= d need
some non-parallelized copying to create such a file anyway.

That would require double the disk space.
But you can also just run pg_dump manually on each database an= d a pg_dumpall -g like people are doing today -- I thought this whole thing= was about making it more convenient :)
=C2=A0
--
=C2=A0Magnus Hagander
=C2=A0Me: https://www.hagander.net= /
=C2=A0Work: https://www.redpill-linpro.com/
--000000000000645a4f061a8e45cc--