On Fri, 2025-10-24 at 11:54 +1300, David Rowley wrote:
> On Fri, 24 Oct 2025 at 09:38, Laurenz Albe wrote:
> > I recommend that you create a primary key on each partition rather than
> > having one
> > on the partitioned table.
>
> It might be worth mentioning that doing that would forego having
I think from a practical standpoint, partitioning directly on uuidv7 is
going to cause problems. You can't directly see the partition constraints,
you have to do tricks like your floor function to make it work, and you
have to be super careful in how you construct your where clauses. However,
what
Greg,
Thank you very much for your recommendations and your sample code. I
originally had it your way, but then I found out this is not possible
create table message (
id uuid PRIMARY KEY
-- ... plus other columns
) partition by range (uuid_extract_timestamp(id));
whereas, this is
create ta
On Thu, 2025-10-23 at 13:11 -0700, Jonathan Reis wrote:
> Thank you very much for your recommendations and your sample code. I
> originally had it your way, but then I found out this is not possible
>
> create table message (
> id uuid PRIMARY KEY
> -- ... plus other columns
> ) partition by
On Fri, 24 Oct 2025 at 09:38, Laurenz Albe wrote:
> I recommend that you create a primary key on each partition rather than
> having one
> on the partitioned table.
It might be worth mentioning that doing that would forego having the
ability to reference the partitioned table in a foreign key
co
Thank you all for your input on this. Here is a summary of what I have
learned from you all.
Approach 1: partition on uuid_extract_timestamp(id)
Pros: No need for custom function to convert from timestamptz to uuidv7
Partitions are human-readable
Can use pg_partman
Cons: Cannot have a
