From: Tom Lane <tgl@sss.pgh.pa.us>
To: Duncan Sands <duncan.sands@deepbluecap.com>
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: Query planning on partitioned table causes postgres 13.4 to
 consume all memory
In-reply-to: <4a3115d4-0fb2-e214-93e3-9a9d0974b883@deepbluecap.com>
References: <4a3115d4-0fb2-e214-93e3-9a9d0974b883@deepbluecap.com>
Comments: In-reply-to Duncan Sands <duncan.sands@deepbluecap.com>
	message dated "Fri, 17 Sep 2021 11:49:06 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1556206.1632067384.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sun, 19 Sep 2021 12:03:04 -0400
Message-ID: <1556207.1632067384@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1556207.1632067384%40sss.pgh.pa.us>
Precedence: bulk

Duncan Sands <duncan.sands@deepbluecap.com> writes:
> [ planning DELETE on a thousand-partition table takes forever ]

FWIW, this situation has been very much improved for v14 [1].
In older branches, the best advice I can give you is "don't use
so many partitions".  Especially not with hash partitioning,
where the query WHERE clause generally won't translate to any
useful pruning of the partitions.

(Personally, I think that hash partitioning is an evil that
we shouldn't have implemented at all.  Or at least there
should be stronger warnings about it in the manual than there
are now.)

			regards, tom lane

[1] https://git.postgresql.org/gitweb/?p=3Dpostgresql.git&a=3Dcommitdiff&h=
=3D86dc90056