Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.100.2.1.4\))
Subject: Re: List Based Table Partitioning on non-Primary Key Columns
From: Scott Ribe <scott_ribe@elevated-dev.com>
In-Reply-To: 
 <CAHER7Lq9jQdhPofpsS2VpvLhBgEDzzY_9QgNHZ5-A2a8xk_eLQ@mail.gmail.com>
Date: Mon, 16 Oct 2023 15:04:13 -0600
Cc: pgsql-admin@lists.postgresql.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <A2497CED-0CF2-4DF8-B041-8E4793A884E8@elevated-dev.com>
References: 
 <CAHER7Lq9jQdhPofpsS2VpvLhBgEDzzY_9QgNHZ5-A2a8xk_eLQ@mail.gmail.com>
To: Amit Sharma <amitpgsql@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/A2497CED-0CF2-4DF8-B041-8E4793A884E8%40elevated-dev.com>
Precedence: bulk

> On Oct 16, 2023, at 2:55=E2=80=AFPM, Amit Sharma <amitpgsql@gmail.com> =
wrote:
>=20
> My question is, is there any downside of using a similar partition =
option in PostgreSQL from performance or manageability perspective? Has =
anyone dealt with a similar type of partition issues? Is there any other =
alternate option we should be using?

It's not unreasonable. But an alternative is to have a set, fewer, =
number of partitions and hash partition. You could wind up with better =
balanced partitions, and the cost of on average larger partitions.