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.96) (envelope-from ) id 1vJbey-00CvBd-0q for pgsql-hackers@arkaria.postgresql.org; Thu, 13 Nov 2025 18:03:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vJbeu-002vtT-0W for pgsql-hackers@arkaria.postgresql.org; Thu, 13 Nov 2025 18:03:00 +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.96) (envelope-from ) id 1vJbet-002vtL-2a for pgsql-hackers@lists.postgresql.org; Thu, 13 Nov 2025 18:02:59 +0000 Received: from mail-qt1-x834.google.com ([2607:f8b0:4864:20::834]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vJber-007aHJ-1q for pgsql-hackers@lists.postgresql.org; Thu, 13 Nov 2025 18:02:59 +0000 Received: by mail-qt1-x834.google.com with SMTP id d75a77b69052e-4edb8d6e98aso21331cf.0 for ; Thu, 13 Nov 2025 10:02:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1763056975; x=1763661775; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=GyK1H1vH0hl8fTo9KPFuqPxwRnfjhsilYGO35Be/Hgc=; b=yzE/biOBiIncKtjZC4ZHgs4iJMFUQZE7Hr04OzCUBJ3Rk1CHpZVhVxgn745MIpAaFe Er4LGrQHQ9MDpDaT5iPQLY8/ntEImQfZEviT/cIp+US7rhqevtLwHw/o0zkZvCsYM49w QIJVvubr2q59AkKccC4Ag+y34FlYqqIMk24oHSwfHYr73zUlXHX1EzXWtYGQKG/Fk3q5 iAXHdYQ3eLjnFqtoGBAGUuZE6a/NlVdv5ltkOT4r7K50nq5UPYnKx5WF/eW04c0oS1tA MRjd3vmOT5PNDTSekwhES+kmopIfpR7gtAumeNJGtvrfktcRUYcMShGQi8XWdAUNCH7K u4fQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763056975; x=1763661775; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=GyK1H1vH0hl8fTo9KPFuqPxwRnfjhsilYGO35Be/Hgc=; b=klqTe+RGm5vAMi2nf5b9MCjLGGOOjXEw2gMlHiWJkqGi6eMgqZAB7whcwBMebpepSb exmAiAn8EBd/zWDLYua4xktaFJMCtGPU7jQdOyTVP9PBQa0LFUEbrvsoxP1fT14B2k3i lb5f5k6arIEUKDeuJYXAFKxhhQ6jaVGBd+Jyr5KFpjX1Zy9jNmZEPvxjlDXBnjlSmgOr +gBbwTAncSHJoXBZ9wa0Ih5Rhiq5q91XS3eah93vW4jB7pKgiOHVsvSVf+94KnBCQEyJ T2pcf+Q9OE4ptYsX2zJh9boPFOg7HpQwGFNOXdOLpphj+suGqDU9RRh1QTEUqvzJt+E5 7c7w== X-Gm-Message-State: AOJu0YwZj5BC9cHB+AKx8+vQqYVhwJ0rpwaqnMbsWpPhJMm9rdXS+bzV bxLwddtEkNY8x2jX5HrjPGDJBhpV1i1ypWCHLCZtyNgZfZfbZQQhCzKMrkgAc0Hs6iDAXzMPwr9 VN8LWmy+S2IwpfE2qpgyC5x4mtSeRY8/VvJMc+KJL X-Gm-Gg: ASbGncuNf/rKjIEXc0amjYQ3VKTte8RS8t8sUFHbQgJiC3Ws13BiWEdKgVk5zw1CWgc CzP6pLAwTm4/lEfmFjpt9/lkrOGrzaY/SM0WKYyAt3TYjS0xpL9vxhPFQb7YSIWmVsL/YBuyEKB Dt1obAJPER9WSI2KvnTl+oIN492V3BnQXoAS6H0KLtBD/mosuH/hTHcl4PTAeAZstusZVmJtR91 3dyj2WwcBaL3NsuwW7nA7wI5CY8mpzhX0ckQIz9bzPtBtJH/0Dr96TI5T6b/Ff6rZN2J81jlx59 Tnk9 X-Google-Smtp-Source: AGHT+IE5J/oEPdKgTqP64dWnmzzs29czkn4uRYOSIjAAEKY4mR3z9iLw0fJvIgSMCJQzymW6kPad0lLNw43uhUAqBME= X-Received: by 2002:ac8:7d11:0:b0:4ed:b4e3:cfa9 with SMTP id d75a77b69052e-4ede8bcb3cbmr7192841cf.5.1763056975091; Thu, 13 Nov 2025 10:02:55 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Hannu Krosing Date: Thu, 13 Nov 2025 19:02:43 +0100 X-Gm-Features: AWmQ_bnSgtQlgoFls5Q5LC8sU7IZ-b-ff6LT_2RuCS-OmddwmGXkUOMQpSXTIjg Message-ID: Subject: Re: Patch: dumping tables data in multiple chunks in pg_dump To: Ashutosh Bapat Cc: PostgreSQL Hackers , Nathan Bossart Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I just ran a test by generating a 408GB table and then dumping it both ways $ time pg_dump --format=3Ddirectory -h 10.58.80.2 -U postgres -f /tmp/plain.dump largedb real 39m54.968s user 37m21.557s sys 2m32.422s $ time ./pg_dump --format=3Ddirectory -h 10.58.80.2 -U postgres --huge-table-chunk-pages=3D131072 -j 8 -f /tmp/parallel8.dump largedb real 5m52.965s user 40m27.284s sys 3m53.339s So parallel dump with 8 workers using 1GB (128k pages) chunks runs almost 7 times faster than the sequential dump. this was a table that had no TOAST part. I will run some more tests with TOASTed tables next and expect similar or better improvements. On Wed, Nov 12, 2025 at 1:59=E2=80=AFPM Ashutosh Bapat wrote: > > Hi Hannu, > > On Tue, Nov 11, 2025 at 9:00=E2=80=AFPM Hannu Krosing = wrote: > > > > Attached is a patch that adds the ability to dump table data in multipl= e chunks. > > > > Looking for feedback at this point: > > 1) what have I missed > > 2) should I implement something to avoid single-page chunks > > > > The flag --huge-table-chunk-pages which tells the directory format > > dump to dump tables where the main fork has more pages than this in > > multiple chunks of given number of pages, > > > > The main use case is speeding up parallel dumps in case of one or a > > small number of HUGE tables so parts of these can be dumped in > > parallel. > > Have you measured speed up? Can you please share the numbers? > > -- > Best Wishes, > Ashutosh Bapat