Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps
 (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <pgsql-admin-owner+archive@lists.postgresql.org>)
	id 1n9Kim-0003P5-52
	for pgsql-admin@arkaria.postgresql.org; Mon, 17 Jan 2022 05:38:24 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.92)
	(envelope-from <pgsql-admin-owner+archive@lists.postgresql.org>)
	id 1n9Kij-0005LO-Fc
	for pgsql-admin@arkaria.postgresql.org; Mon, 17 Jan 2022 05:38:21 +0000
Received: from makus.postgresql.org ([2001:4800:3e1:1::229])
	by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <vas@sibptus.ru>)
	id 1n9Kij-0005LF-5D
	for pgsql-admin@lists.postgresql.org; Mon, 17 Jan 2022 05:38:21 +0000
Received: from admin.sibptus.ru ([2001:19f0:5001:21dc::10])
	by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <vas@sibptus.ru>)
	id 1n9Kig-0003nn-16
	for pgsql-admin@lists.postgresql.org; Mon, 17 Jan 2022 05:38:20 +0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sibptus.ru;
	s=20181118; h=In-Reply-To:Message-ID:Subject:To:From:Date;
	bh=tS+V34I4uJ/CKWJuPxRv6DU1e3gT5kaDF3VrNhS68bw=; b=TGFN15hveSdbTAILFdGNnQURG2
	b3Axp5edvx3ozfSQoBCOwkYvxNIIQFMI544i0oN9GnUW5UINeOajMJLG4FxkFTzoT9OK001ZF/9ZQ
	dX5ozb3tetI8THLiGg+huSp/ZAkeWrNf+lzoRHdZqrG7ryV66cFjCfYWPkGdT/7HjkYE=;
Received: from vas by admin.sibptus.ru with local (Exim 4.94.2 (FreeBSD))
	(envelope-from <vas@sibptus.ru>)
	id 1n9Kid-0005Cl-G8; Mon, 17 Jan 2022 05:38:15 +0000
Date: Mon, 17 Jan 2022 05:38:15 +0000
From: Victor Sudakov <vas@sibptus.ru>
To: pgsql-admin@lists.postgresql.org
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: Large number of partitions of a table
Message-ID: <YeUAx56Juri43xGY@admin.sibptus.ru>
References: <YeTYA63gEXNePfkv@admin.sibptus.ru>
 <3919502.1642393668@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3919502.1642393668@sss.pgh.pa.us>
X-PGP-Key: http://admin.sibptus.ru/~vas/
X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9  3532 0DA4 F259 9B5E C634
List-Id: <pgsql-admin.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-admin@lists.postgresql.org>
List-Owner: <mailto:pgsql-admin-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-admin>
Archived-At: 
 <https://www.postgresql.org/message-id/YeUAx56Juri43xGY%40admin.sibptus.ru>
Precedence: bulk

Tom Lane wrote:
[dd]

> The specific point that depesz was responding to in that blog
> was the 64K-ish limit on rangetable entries in a query.  That is
> a thing, as he could have shown by using queries that weren't
> amenable to plan-time pruning.  (It's also an ex-thing, having
> been fixed for v15 [1]; but that doesn't help you today.)
> Now, if you use no queries that can't be pruned to a few
> partitions, then it's academic for you.  

The table will be partitioned `BY LIST (customer_id)` which is a unique
index. All queries will be using this index so no query should ever
have to use more than 1 partition.

This means basically I'm OK?

-- 
Victor Sudakov VAS4-RIPE
http://vas.tomsk.ru/
2:5005/49@fidonet