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 1wPf1I-000vrP-2V for pgsql-general@arkaria.postgresql.org; Wed, 20 May 2026 11:23:24 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wPf1G-007J1q-2U for pgsql-general@arkaria.postgresql.org; Wed, 20 May 2026 11:23:23 +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.96) (envelope-from ) id 1wPf1G-007J1h-1R for pgsql-general@lists.postgresql.org; Wed, 20 May 2026 11:23:23 +0000 Received: from mail-vs1-xe33.google.com ([2607:f8b0:4864:20::e33]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wPf1E-00000000TiC-3ddt for pgsql-general@lists.postgresql.org; Wed, 20 May 2026 11:23:22 +0000 Received: by mail-vs1-xe33.google.com with SMTP id ada2fe7eead31-631b313e3d0so1446075137.3 for ; Wed, 20 May 2026 04:23:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1779276201; cv=none; d=google.com; s=arc-20240605; b=HOeILEj33kjKiCbWuF29d6LTkr7O1kSAnPkMooEZ/d0CXYsU15D8cTKN4Ou/SVLLdj eCAwZ5zSu43CYIQtvU/xSSh2F1oU5yGrP6vLKmHWDHlwAtNobS+6tknUr3AVQJ5xgrV/ Crhv9R1ZcN/UohrY3QStr2uHTVAjUYvMyFMAQXTLp1Ecuhtz8cOBKv6aRP10ji7XkZQo Qk4SLi11geEOIiQId/tWxQaZZO2IUtb/2TCV6xtHRvvZdNcZSgNnJr1i5nlyKX+TiR9y 6dkdYLsRKd5nQKqklMK7vD0KbqZ35ulHMeul0RtMAsZ/GDiura1MGT8kCEo6RKs1PyaT x1Rg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=paE6V00xocfxKmJ96p8SvPVfYk4fcrpTidiP16w6fas=; fh=jfgljk/sYofytMb5uk8+Q45tUOncYvXlAfPxvtRfPpY=; b=T83V+aZeY5xTCQc7GkIq0G8CIc3V9EkLSFoPy84jfPDOcMg108WP3Kyf7rHjF2FHd2 DKSoR6XZ4/Ri9PYXOGOM7bvCaEo8YRmwEUHwnooLuX8mFWWLD6uHJT7eRQUlCmu86FBW uS03ajG50IT/OOk3867EgK5h5aAC7h9p7SsWGDl/B7oABzcaHnKuvSv+rKiU0DZ1Z/mI kxYO8Ywr5v89yl2+Dqtr5DS9xc5KFEG2+cCEz6vHff1vfI4eveIQGtGeeaJrogMBPxlr Y8EEzqQcrnTNYrH0RohdBJmIPGmiKPXxbCcAGKm7dBwLrhkfTStM+egpE2t1KFMLvKj4 T+qw==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779276201; x=1779881001; 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=paE6V00xocfxKmJ96p8SvPVfYk4fcrpTidiP16w6fas=; b=RKEiAWSjN5GrCb1PHao/L26UuQYQXIGN5RL79PX66F3geZfF6opfS2i2Wq0YkoT3+m 0WTLfM5heD9VT8AuLWDtpU9GRNtVEcm9rIZnFNeJ2TySi+Sg5/n1CXDrRCU3qUT9rycs 3muQ42tMvpYvLLoDsE1GscC+Uj0pikiizFKaWJb9jJat6nUuQ8sZRXmAOh7SngN5K7ay uSpfnKFEEKD4HKVsfx3TeZF9I1k+Cc2mRqjiuo+/ESQEcNtvPIel29cnELz1WGzG8JSx tmzLLxyz8Mdx+afs1LT9gLfeAfXd8T61XZMVL1F/gPVXeoT1yG94qRsXfG+iKzCJUFwE sYOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779276201; x=1779881001; h=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=paE6V00xocfxKmJ96p8SvPVfYk4fcrpTidiP16w6fas=; b=n4a51ghZTiQWu19c5PSvEb3Anh3IcZE3oUFqGwfbMK/knNpuUL4BqUzv1QD4phGSv2 OR4vMp5XOOQao9GCHmLJsdtKjQIW7brWTmAEroOrDCQ2eSqyW60WcPE/tMKSPaRJohMK +qlp5gYquPLmgKUohqYMNaTGrhOjZ2IV1hdXY+GOpjmgW65cCraWrFeQfu6jbzxGLhij cV2TfuRU60YrLL9B4brDn6oxcXZ6HYGElS6Yz4rlpntOui5WRuDTnAh37RiPD54cpYJr T60v9smRWAmu8d//d5y4jqXxw6/hgSGGJasXlEC9flX4aCvXd8Ebaxk2vuKaB95DIw9W BWZQ== X-Gm-Message-State: AOJu0YyXz8bCRB7bSKyyTk8ayqdh+lspSQ8tw9/8cHIdctK3K55dLQ54 blFTxrO7pBj5SwP+bHViBq6olkHRVGZ/VLa8mf8t2q+pNFsRUBS+VgGKTOWdvF0I7heCFqeizMk y3hCiEqKKLuNAuHMSP4whvphfTUFcxes= X-Gm-Gg: Acq92OFMVUukA2K8TXWz7EhFUA3Mbk8t8Ez2w1QjK0THQKsAfzz3S4/ifSbDH09mywM +//BOWW0CDCEDoqmwsfIdyhi3/+kSVkuOegSYuCF3Uu1gSnFtTU7Uoq3d2VBi5UZ02xJFtDhBiC hX9teuIbs0BZjhxPYGNWksYQkjjM9WvRKdUO6al13iSNu+qIEAScuxJtTzUnXkAzlQyaWgqvzfa Ya7UXWgc3L/xBUFygIkwk4S6BotMeEWgo1Jbbvs6kx6rTHf2suTZ4P8BJNVdZnPeGKXBK4Yggqc k/4kkhe1ulTxlnX9uqFo X-Received: by 2002:a05:6102:8650:20b0:650:9173:b131 with SMTP id ada2fe7eead31-6509173bcf2mr5067404137.5.1779276200686; Wed, 20 May 2026 04:23:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Priancka Chatz Date: Wed, 20 May 2026 13:23:09 +0200 X-Gm-Features: AVHnY4K3MFpM-o1td-3W-tvgGDcB8CRRIrIBJmRGC-ik7mQZOirwQcWwKR64EZs Message-ID: Subject: Re: Large backup size of pg_dump To: =?UTF-8?B?RXJ0YW4gS8O8w6fDvGtvZ2x1?= Cc: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000e63b6306523e0536" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000e63b6306523e0536 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable When you store large objects, the actual data resides on pg_largeobject table (https://www.postgresql.org/docs/current/catalog-pg-largeobject.html)= . So your "app" table might not be the only thing to exclude in your dump. Regards, Priyanka Chatterjee On Wed, May 20, 2026 at 9:18=E2=80=AFAM Ertan K=C3=BC=C3=A7=C3=BCkoglu wrote: > Hello, > > I am using PostgreSQL 18.4 x64 on Windows Server 2022. There is a very > small single database in the cluster. > > There are hourly pg_dump backups scheduled and database backup size is > around 10GB. > > command line is like below > pg_dump.exe -p 5432 -U dbuser --exclude-table=3Dapp -F p -b -c -f > "hourly.bak" > > When I check the cluster directory size it is 4.1 GB. > > Database has one BLOB saved in a single record and it is 16MB in size and > that is in the "app" table which is excluded from the backup file. > > I didn't understand about 2.5 times bigger backup sizes than the total > cluster size. I do not know what to check either. Is there a way for me t= o > make the hourly backup size smaller? > > Thanks & Regards, > Ertan > --000000000000e63b6306523e0536 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
When you store large objects, the actual data resides on p= g_largeobject table (https://www.postgresql.org/docs/current/catalog-p= g-largeobject.html). So your "app" table might not be the onl= y thing to exclude in your dump.

Regards,
Priy= anka Chatterjee

On Wed, May 20, 2026 at 9:18=E2= =80=AFAM Ertan K=C3=BC=C3=A7=C3=BCkoglu <ertan.kucukoglu@gmail.com> wrote:
Hello,

I am using PostgreSQL 18.4 x64 on Windows=C2=A0Server 2022. There is= a very small single database in the cluster.

Ther= e are hourly pg_dump backups scheduled and database backup size is around 1= 0GB.

command line is like below
pg_dump.= exe -p 5432 -U dbuser --exclude-table=3Dapp -F p -b -c -f "hourly.bak&= quot;

When I check the cluster directory size it i= s 4.1 GB.

Database has one BLOB saved in a single = record and it is 16MB in size and that is in the "app" table whic= h is excluded from the backup file.

I didn't u= nderstand about 2.5 times bigger backup sizes than the total cluster size. = I do not know what to check either. Is there a way for me to make the hourl= y backup size smaller?

Thanks &=C2=A0Regards,<= /div>
Ertan
--000000000000e63b6306523e0536--