| From: | Jacob Jackson <jej(dot)jackson(dot)08(at)gmail(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
| Cc: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Proposal: Add a UNIQUE NOT ENFORCED constraint |
| Date: | 2026-01-08 02:18:12 |
| Message-ID: | CAAiQw3ztdVE0E5iVGrZ_eGLVoZ6EoMaB+bo6_Lfb4XdmK7fHwQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jan 7, 2026 at 2:12 PM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
> Some other SQL implementations have optional implementation-specific
> modes on top of NOT ENFORCED that mean, the constraint is not enforced,
> but you can assume it holds for query planning purposes. This is
> probably what the thinking here was, but that is not how PostgreSQL
> currently works, so additional work would need to be done to add this
> additional mode.
>
> There are probably also multiple levels to this. It's one thing to use
> an unenforced-but-probably-true constraint for things like selectivity
> estimation, where you just get a worse plan if it's not quite true, but
> it's another to assume something is unique when it might not be. So
> there is some research to be done here.
Yeah, after reading through Matthias's and your comments, I am
increasingly convinced that the best option is to add a separate
trusted/untrusted flag that would decide whether Postgres allows any
query plans that could change results if the data isn't actually
unique. It seems feasible, but I haven't worked on implementing it
yet.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2026-01-08 02:38:58 | Re: Refactor query normalization into core query jumbling |
| Previous Message | Chao Li | 2026-01-08 02:07:21 | Re: Refactor replication origin state reset helpers |