Re: Performance implications of partitioning by UUIDv7 range in PostgreSQL v18

From: Jonathan Reis <jon(dot)reis(at)conevity(dot)com>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, Greg Sabino Mullane <htamfids(at)gmail(dot)com>, Olof Salberger <olof(dot)salberger(at)gmail(dot)com>, pgsql-performance(at)lists(dot)postgresql(dot)org
Subject: Re: Performance implications of partitioning by UUIDv7 range in PostgreSQL v18
Date: 2025-10-24 15:24:46
Message-ID: CAE_7N3639q922kKsLWn2KK0qQfeV0ggck9t6S7GQGxaKwpVUWg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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(dot)albe(at)cybertec(dot)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(dot)albe(at)cybertec(dot)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
>

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Carlo Sganzerla 2025-10-27 18:17:23 GEQO plans much slower than standard join plans
Previous Message Greg Sabino Mullane 2025-10-24 12:38:57 Re: Performance implications of partitioning by UUIDv7 range in PostgreSQL v18