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 1wJY34-000Y7B-1E for pgsql-general@arkaria.postgresql.org; Sun, 03 May 2026 14:43:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wJY33-003iOr-0q for pgsql-general@arkaria.postgresql.org; Sun, 03 May 2026 14:43:57 +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 1wJY32-003iOi-2b for pgsql-general@lists.postgresql.org; Sun, 03 May 2026 14:43:56 +0000 Received: from mail-oa1-x36.google.com ([2001:4860:4864:20::36]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wJY30-00000000E6l-3v6C for pgsql-general@postgresql.org; Sun, 03 May 2026 14:43:55 +0000 Received: by mail-oa1-x36.google.com with SMTP id 586e51a60fabf-42fe552aedeso805346fac.0 for ; Sun, 03 May 2026 07:43:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1777819434; cv=none; d=google.com; s=arc-20240605; b=CwQfEWNOgn7+r4Sl4jGRLH7oODX6B/Ve59bwK/itx8jaTe+zxyt8ZKqNW4YfYsdekN uuOTttO/r9MhsjIupZh4Gm/JaW1fxG3lq+HuYw5+42zfNJor2AEj06xg4UceC2K+P41y ppoQg4TOXd186NAQ2znyxpuMW6amQqem/Tc0iDzDx//HMW18P9itbXl9cBpA5v3tvwCm zpJk+aLbTBOBetHPCeZbuRg5gsWa6QyljJYmSEbRbI7sit1dq/8Pd67iUsKnsj+V2fpL Sh0Z6cpgl8096iF3SqTie2T+ny1tP9DqEOdBtTgKiYvs0qMYlJGjfjMzsQolaNWPEb5d vTnA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=YWHlQfTUpPnIN6NhNrHng6NWxazBxnb/MXaDF6Ut/pU=; fh=KNSq+t9BltSXFnT3Yof/aKGBtqxeA+bTALiYdvTslaY=; b=ekTbqLr5BK6QvsH6oy3CRCJstU2QOU6eteRRVtShtJcgUwzJcTcPfGUR1e/kUwKpk/ XbPinIRLgbSKorvvD60ws3A31Lf9/8mx2YFqCGTzgUwjgFHXks8wklbcuog2S9Uva9d7 nX93GH1zJqN5T/ts8tRlEAOIuTX2mhPcI5M15zqXriqHC7LhNeXGjpJALCbUvCKif4Ce pHiE+ysZzx58/8Gcqg9yhxIJ+axgIMW+7mPNwdVaxklxtNgbNuFf0UQrUdKHmBR0Yt+h AEvxPCUlhG+5g60DFMGPjZOskh4Q8Ur3V1r4FBc1XMWB/CNyFsBlbMmHQW9qwK5XjAsW eTOg==; darn=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=1777819434; x=1778424234; 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=YWHlQfTUpPnIN6NhNrHng6NWxazBxnb/MXaDF6Ut/pU=; b=BamzwRJwEYrh8rkjuWVYHjQWkPKXgai/s6pao9QCWkCUqIFFBSdUJRidK6b3P2i2Hh KGG0hLeW0vHKeiGKLUtpbxvse17K6iZtGvO2NhbR7PB2LKdrrsY0EWlhdWx20j82gCOx OzZ5khsm5TUzS3W4E5HNifTEkX6ZMRusk6Hu7Hboh/125XzMKnRT+RE/wsEb6afKyIFd sSZTenl+um3loS+1cSHGKcrOqjPxxhBuVPun35HWXZ9h0xS/wYDjr8YD4JJtS3bpThCL bDt8Dqk0Xzbhf6RyJw5UX7HCUHHTG3FvHvQ/XXsU2RS6MOM/N1unR+xDyo8pXwvEf9VF bjLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777819434; x=1778424234; h=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=YWHlQfTUpPnIN6NhNrHng6NWxazBxnb/MXaDF6Ut/pU=; b=cRQs6iiLnAUbOroBAXTWOMxHPTkDfXXs4HK/eKevUvvftu5xDhnYsBV8U0roqggHsC 8dd26QHV14/eTIHtrY+tk7owOh0f4b6CZMtAyHuL/3zyYGu6s+Zmfyzr+4HdUHbYMLGk sAESeWS8lFUQKOinDLWIWX+Kn6ke6skY3sAy1KbIy3B50J70k94DQkdLasvCsBWaYuqw +J0JW6zJH1y692KiQd6hHD4IX2OQDzYC3+XVPg7pul41TWxqR0n3Dtp/c2jrKaCjQ7vL lKiauRA8OGaRZmiPI44oyr+2ggUCax+ede8trVtj2TEbt4hFGTdNp6BcC9lnHWRmugog lsnQ== X-Gm-Message-State: AOJu0YyfjlOO8lZLSyiy2LeGPy6eQWCpwaaJPgE4Y0wpFEZYozbVkyDN GXMi2A2vIYqEbsdxtxOLV7GlG3pS+2ZPc+o38aBR7jI1jK7oG3sTw9NyLRtgC1a1Cv9x2DDh18z R8ASF0NBKX1McP+V2sQBYtRPInAVIHRvzzw== X-Gm-Gg: AeBDietKR4di8NaUi3OHinYBaNPhWzn2BNGZGkKLQfv0Sna8z8baHdR9Fdyv84sgiEe om/MACTXZm0d9moz8Ou/88OMUpU/XCtogSWtDZLeQ4uyrNgvQWgQNCCS701AOn/9V/7gFvZ+IVr W0mn9APqujVKKGP9DuqkoNmDExIxfyzIv4HfO33pAiBH7XpU8XWWfrvwo6x/QRSbg8/9U/NhTJl BGvf7etFStY6L7f5tWXI2SR3m9YRD7bNTNFFYMg69iiPzV8zCpJcNm6UkBJpNFIeiKXzHKWh0Na 8sDq9zzcXJmGZjGFSo0= X-Received: by 2002:a05:6820:1987:b0:696:154b:24e with SMTP id 006d021491bc7-69697c65299mr2891574eaf.32.1777819434011; Sun, 03 May 2026 07:43:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ron Johnson Date: Sun, 3 May 2026 10:43:43 -0400 X-Gm-Features: AVHnY4IttWA9C30pnUgxL94L2ewhQ79lB9PkdZvj6gFj8dbmJHFUuKpZ1TzvIzQ Message-ID: Subject: Re: Tablespace size in TB To: pgsql-general Content-Type: multipart/alternative; boundary="000000000000d6cf990650ead7ea" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000d6cf990650ead7ea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, May 3, 2026 at 5:36=E2=80=AFAM masheed ullah wrote: > Hi, > > Postgres =3D Version 13 > > OS=3DLinux Redhat version 8 > > Our team is using a single tablespace for the whole database. Its size is > more than 13TB. I am from an Oracle background and want to suggest that > they split the data in multiple tablespaces. It will not only improve the > performance & reduce the backup time. > > But I did not find any Postgres best practice or blog, to show as a > reference. > To reinforce Jan's comment: a PG tablespace is *just a directory*. Nothing more, nothing less. If your 13TB database is on one single spindle (or even SSD/NVMe), then yes, adding more spindles or SSDs would be useful. But if it's already on multiple spindles, then LVM solves the problem for you. As for long backup times, that's a function of hardware. How many threads are you using? How parallel is the backup disk (or SAN)? How's the network configured? Etc etc. --=20 Death to , and butter sauce. Don't boil me, I'm still alive. lobster! --000000000000d6cf990650ead7ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, May 3, 2026 at 5:36=E2=80=AFAM ma= sheed ullah <masheedullah@gmai= l.com> wrote:
=
Hi,=

Postgres= =3D Version 13

OS=3DLinux Redh= at version 8

Our team is using = a single tablespace for the whole database. Its size is more than 13TB. I a= m from an Oracle background and want to suggest that they split the data in= multiple tablespaces. It will not only improve the performance & reduc= e the backup time.

But I did not find any= Postgres best practice or blog, to show as a reference.


To reinforce Jan's comme= nt: a PG tablespace is just a directory.=C2=A0 Nothing more, nothing= less.

If your 13TB database is on one single spin= dle (or even SSD/NVMe), then yes, adding more spindles or SSDs would be use= ful.=C2=A0 But if it's already on multiple spindles, then LVM solves th= e=C2=A0problem for you.

As for long backup times, = that's a function of hardware. How many threads are you using? How para= llel is the backup disk (or SAN)?=C2=A0 How's the network configured?= =C2=A0 Etc etc.

= --
D= eath to <Redacted>, and butter sauce.
Don't boil me, I'm = still alive.
<Redacted> lobster!
=
--000000000000d6cf990650ead7ea--