Re: Performance implications of partitioning by UUIDv7 range in PostgreSQL v18 - Mailing list pgsql-performance

From Jonathan Reis
Subject Re: Performance implications of partitioning by UUIDv7 range in PostgreSQL v18
Date
Msg-id CAE_7N3639q922kKsLWn2KK0qQfeV0ggck9t6S7GQGxaKwpVUWg@mail.gmail.com
Whole thread Raw
In response to Re: Performance implications of partitioning by UUIDv7 range in PostgreSQL v18  (Laurenz Albe <laurenz.albe@cybertec.at>)
List pgsql-performance
Great point. One of the main reasons we are using partitioning is to quickly drop partitions containing old data so we wouldn't be implementing foreign key constraints any way.

On Thu, Oct 23, 2025 at 10:04 PM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
On Fri, 2025-10-24 at 11:54 +1300, David Rowley wrote:
> On Fri, 24 Oct 2025 at 09:38, Laurenz Albe <laurenz.albe@cybertec.at> 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
> constraint.

Right, but referencing a partitioned table with a foreign key is a mixed blessing
anyway: you could no longer drop partitions from the partitioned table without
scanning the referencing table to verify that the foreign key is not violated.

Yours,
Laurenz Albe

pgsql-performance by date:

Previous
From: Greg Sabino Mullane
Date:
Subject: Re: Performance implications of partitioning by UUIDv7 range in PostgreSQL v18
Next
From: Carlo Sganzerla
Date:
Subject: GEQO plans much slower than standard join plans