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 1uTP6D-00453y-4z for pgsql-general@arkaria.postgresql.org; Sun, 22 Jun 2025 18:07:25 +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 1uTP69-00EI7s-Qw for pgsql-general@arkaria.postgresql.org; Sun, 22 Jun 2025 18:07:22 +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 1uTP69-00EI6e-BE for pgsql-general@lists.postgresql.org; Sun, 22 Jun 2025 18:07:22 +0000 Received: from mail-ed1-x529.google.com ([2a00:1450:4864:20::529]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uTP68-003Q06-15 for pgsql-general@lists.postgresql.org; Sun, 22 Jun 2025 18:07:21 +0000 Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-605b9488c28so5902684a12.2 for ; Sun, 22 Jun 2025 11:07:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1750615638; x=1751220438; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=yQFjyU8Cj6yw940G0EwqeRT7Hdq7f2TcFP7H++7Vwno=; b=jg+ln7Bx+T+laRLWONkOCH6swTAuExS+xpMNEgcL7I3Wq7RKSPdf1CBbCTXm79Kubh jvAlszmAIAM9yQnUqpr0W8Sl3r2U32aPgEHFcjVrmPoQnED9ngtLiTaRHvwwpDPa7gcJ JGqVOdPPUqLSIzaGbhx44Ir/kI7rzYYizdCwusnmvi8m6w098afMAX2X4SQW5GqP2mW9 QQZldedD/lkgVvezrTZP2IDm/EVroGlEi4R/VsZ/yLP4eVPKL2puxpCDprwIVORSSKTK zVXXab4qy+t1OOV+zjkWUlbbKlN0kvOsR8UbQIuAqeUsfqtdS1jj0jWni5d860flNcKD 2W9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750615638; x=1751220438; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=yQFjyU8Cj6yw940G0EwqeRT7Hdq7f2TcFP7H++7Vwno=; b=Wtc4KbyKkh8crKXlR+XezQ8p9u4W5+AXhaWpukCxku2VL+YWwQH5qVBls++MdZ6YOm 9C7FdboG1SWJlVQn7rahN+DjLh+mvnh9c9QDBRr/feTUlRUVejO0mpvRc5EDcYBHbhbF MhsFYltydMnmJ2fCCqksBOGMN37sS24lc/FvA4AMiTvzPeYwMELmrnjhL5/QPJxci/BS ttZ1n+rYrTmM1in34fWNs5bK1OUdMXH8OStZlWviBiwSTT6DlSoS/1iMFcr58GYpRiir 5GQroUqlxG0Mp6/hp7ToTVyDX8yPmj+ffdd3qrz6P4x5UyN09LIpRgmdIbwy2NGvWdAo hMEw== X-Gm-Message-State: AOJu0YxhKY6PQSW6PQYiDIdY6stNFW3T5XhDjUP0h3WZK5wkJWxvbtYp A+LEd3BfGMy9QjdsgVFGha+6Dlt5WyOMjabw6FtHOhajImvzJIVVAT2fV9+EXk7FGN/C/XFywVT rkkvr7uFEiHv8lX8YTVB3vJ4wVYmEiLxGszY+OtU= X-Gm-Gg: ASbGncvpfbKLz5SsKk/v/FaNDIBJxkQyc5RoB2WiJz+DEL0+cybpFkK93oYVkYsP27i 2qOZg8jr1WKyoMPNAGg5JX9gSOE2mC1Ckt66vk65dVYbMexMIf7HSrRriN5rjoZUHlwRhLLQb8P 8pMjvviaOlaxy3ie9K8Z1pH5wed7/6Fp9qEl2w5TJq X-Google-Smtp-Source: AGHT+IHhqvCrimvhOtcLUM3fEJ5EIY8jyqBYHTsooan5ik/Xs5uEVPCguhyTREUDDDR8lQyh4d4iw+BI0AiQvprW7UQ= X-Received: by 2002:a05:6402:2744:b0:608:64ee:e7ed with SMTP id 4fb4d7f45d1cf-60a1cc7bfdcmr8461083a12.0.1750615637585; Sun, 22 Jun 2025 11:07:17 -0700 (PDT) MIME-Version: 1.0 From: =?UTF-8?B?Q8Opc2FyIE11w7Fveg==?= Date: Sun, 22 Jun 2025 20:07:06 +0200 X-Gm-Features: AX0GCFv1Ix2H7V7S8Je1d3Zu9TbUsdNNkJCYUVsBweSfE6VodqhlHW-VtyIGMoU Message-ID: Subject: Memory overhead of a large number of partitions in the same table To: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="0000000000003774b206382cf78a" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000003774b206382cf78a Content-Type: text/plain; charset="UTF-8" I would like to understand how much can partitioning can contribute to memory usage in Postgres backend processes. My application mainly runs SELECT statements in a partitioned table. The table is partitioned by size (100K rows per partition, 730 partitions in total). However, each Postgres backend process to run these SELECTs takes ~300 MB in memory, which seems a lot compared to what I've seen around. work_mem is set to 16MB, so nothing too crazy. Also, I am using Pss to measure the memory used by each backend process so that shared_buffers don't mess the whole thing. Here's the output for a couple of them Pss: 1260383 kB Pss_Anon: 305501 kB Pss_File: 199 kB Pss_Shmem: 954682 kB Pss: 1247796 kB Pss_Anon: 293041 kB Pss_File: 200 kB Pss_Shmem: 954554 kB Is this expected? Or the overhead of partitions should be smaller in terms of memory consumption? I'm using Partman to partition the table. Also, shared_buffers for this instance is 25GB with a total of 60GB memory. I can provide output for explain (analyze, buffers) if needed, but the main index used for queries is fully in memory (it takes around 18GB of space). --0000000000003774b206382cf78a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would like to understand how much can partitioning can c= ontribute to memory usage in Postgres backend processes.

My applicat= ion mainly runs SELECT statements in a partitioned table. The table is part= itioned by size (100K rows per partition, 730 partitions in total). However= , each Postgres backend process to run these SELECTs takes ~300 MB in memor= y, which seems a lot compared to what I've seen around.

work_mem= is set to 16MB, so nothing too crazy. Also, I am using Pss to measure the = memory used by each backend process so that shared_buffers don't mess t= he whole thing. Here's the output for a couple of them

Pss: =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1260383 kB
Pss_Anon: =C2=A0 =C2= =A0 =C2=A0 =C2=A0 305501 kB
Pss_File: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0199 kB
Pss_Shmem: =C2=A0 =C2=A0 =C2=A0 =C2=A0954682 kB

Pss= : =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1247796 kB
Pss_Anon: =C2=A0 = =C2=A0 =C2=A0 =C2=A0 293041 kB
Pss_File: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0200 kB
Pss_Shmem: =C2=A0 =C2=A0 =C2=A0 =C2=A0954554 kB

= Is this expected? Or the overhead of partitions should be smaller in terms = of memory consumption? I'm using Partman to partition the table.
Also, shared_buffers for this instance is 25GB with a total of= 60GB memory. I can provide output for explain (analyze, buffers) if needed= , but the main index used for queries is fully in memory (it takes around 1= 8GB of space).
--0000000000003774b206382cf78a--