| From: | Neil Chen <carpenter(dot)nail(dot)cz(at)gmail(dot)com> |
|---|---|
| To: | Jacob Jackson <jej(dot)jackson(dot)08(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Proposal: Add a UNIQUE NOT ENFORCED constraint |
| Date: | 2026-01-07 10:22:01 |
| Message-ID: | CAA3qoJ=-+qXQWdnwmrh4pkCbSM0F6WgWRqw8uyx0=NUZYF8QNw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Jacob,
On Mon, Jan 5, 2026 at 1:34 AM Jacob Jackson <jej(dot)jackson(dot)08(at)gmail(dot)com>
wrote:
>
> In many cases, the idiomatic/generally best way to write a query
> requires a uniqueness check (a SELECT WHERE ... = ANY()/IN or really
> any semi-join when optimized to an inner join, UNION, etc), meaning a
> Unique/HashAggregate node will be added, increasing overhead unless
> there is an explicit unique constraint. An unenforced unique
> constraint would allow developers to use their knowledge of the
> data/previous validation procedures to eliminate the extra node. This
> would also help with documentation/observability tools by providing
> more context on the data without adding overhead.
>
>
I'm not very familiar with the UNIQUE NOT ENFORCED constraint, so apologies
if I make any mistakes here. If we want the query planner to generate an
execution plan as if a column were unique, would setting n_distinct = -1 in
the table statistics achieve the same effect?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Japin Li | 2026-01-07 10:52:05 | Re: Remove deprecated role membership options from psql help for CREATE USER/GROUP |
| Previous Message | Hayato Kuroda (Fujitsu) | 2026-01-07 10:07:11 | RE: Simplify code building the LR conflict messages |