MIME-Version: 1.0
References: 
 <CAE_7N37MopcS6SYmsphE7UxQ9bJTyvgsmVb-NyCncy7fzkiC4Q@mail.gmail.com>
 <CAE_7N37Amq_G6bZDpv9tbxcZJNGVhSv8mt2MJgdZTqGO5Pdbnw@mail.gmail.com>
 <CAD39LRHMO7nEKhub=RyeZH=+Qw=qo6gSNuByDLWsR9-EDmGjhg@mail.gmail.com>
 <CAKAnmmJq3_wFNp4RN15t_YRv9xARVby7=-4PrADwPuaQQYC6JA@mail.gmail.com>
 <CAE_7N35fiC7Rq03hWutO3tPGfADQeO_gQzKHru1iNiASmUdsPQ@mail.gmail.com>
 <cc128c674065c06ebc0d1eb5e76fa2598e78c1c9.camel@cybertec.at>
 <CAApHDvqcjH9y_ofuBB8XnFA1JPZEcYSLzGss1+i9xPTcmcHLjQ@mail.gmail.com>
 <b0991c2d8348da5b97bb0cdb1fe7a3d6a21a0df6.camel@cybertec.at>
In-Reply-To: <b0991c2d8348da5b97bb0cdb1fe7a3d6a21a0df6.camel@cybertec.at>
From: Jonathan Reis <jon.reis@conevity.com>
Date: Fri, 24 Oct 2025 08:24:46 -0700
Message-ID: 
 <CAE_7N3639q922kKsLWn2KK0qQfeV0ggck9t6S7GQGxaKwpVUWg@mail.gmail.com>
Subject: Re: Performance implications of partitioning by UUIDv7 range in
 PostgreSQL v18
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: David Rowley <dgrowleyml@gmail.com>,
 Greg Sabino Mullane <htamfids@gmail.com>,
	Olof Salberger <olof.salberger@gmail.com>,
 pgsql-performance@lists.postgresql.org
Content-Type: multipart/alternative; boundary="0000000000009eb8d10641e928db"
Archived-At: 
 <https://www.postgresql.org/message-id/CAE_7N3639q922kKsLWn2KK0qQfeV0ggck9t6S7GQGxaKwpVUWg%40mail.gmail.com>
Precedence: bulk

--0000000000009eb8d10641e928db
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=E2=80=AFPM Laurenz Albe <laurenz.albe@cyberte=
c.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
>

--0000000000009eb8d10641e928db
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:&quot;trebuchet ms&quot;,sans-serif">Great point. One of the main =
reasons we are using partitioning is to quickly drop partitions containing =
old data so we wouldn&#39;t be implementing foreign key constraints any way=
.</div></div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=
=3D"ltr" class=3D"gmail_attr">On Thu, Oct 23, 2025 at 10:04=E2=80=AFPM Laur=
enz Albe &lt;<a href=3D"mailto:laurenz.albe@cybertec.at">laurenz.albe@cyber=
tec.at</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">On Fri, 2025-10-24 at 11:54 +1300, David Rowley wrote:<br>
&gt; On Fri, 24 Oct 2025 at 09:38, Laurenz Albe &lt;<a href=3D"mailto:laure=
nz.albe@cybertec.at" target=3D"_blank">laurenz.albe@cybertec.at</a>&gt; wro=
te:<br>
&gt; &gt; I recommend that you create a primary key on each partition rathe=
r than having one<br>
&gt; &gt; on the partitioned table.<br>
&gt; <br>
&gt; It might be worth mentioning that doing that would forego having the<b=
r>
&gt; ability to reference the partitioned table in a foreign key<br>
&gt; constraint.<br>
<br>
Right, but referencing a partitioned table with a foreign key is a mixed bl=
essing<br>
anyway: you could no longer drop partitions from the partitioned table with=
out<br>
scanning the referencing table to verify that the foreign key is not violat=
ed.<br>
<br>
Yours,<br>
Laurenz Albe<br>
</blockquote></div></div>

--0000000000009eb8d10641e928db--