MIME-Version: 1.0
References: <156760275564.1127.12321702656456074572@wrigleys.postgresql.org>
 <20190927163747.GE31412@momjian.us>
In-Reply-To: <20190927163747.GE31412@momjian.us>
From: Tuomas Leikola <tuomas.leikola@gmail.com>
Date: Wed, 23 Oct 2019 14:35:02 +0300
Message-ID: 
 <CALhc4GAq4H9DSeC7tU6Nkr34zykiA4g8WQ+suWmXSXTDApgHEA@mail.gmail.com>
Subject: Re: uniqueness and null could benefit from a hint for dba
To: Bruce Momjian <bruce@momjian.us>
Cc: pgsql-docs@lists.postgresql.org
Content-Type: multipart/alternative; boundary="0000000000006578fa0595924fae"
Precedence: bulk

--0000000000006578fa0595924fae
Content-Type: text/plain; charset="UTF-8"

That is a nice design. You can create a regular unique index where
columns(s)s are not null and then filtered index(es) for the cases where
some of the unique columns are null.

However my point, specifically, was that if the document in question would
have offered alternative solutions, I personally would have been saved from
some frustration and an exercise in bad index design (I had 5 nullables
that need uniqueness for the null as well). Maybe it would help someone
else.

On Fri, Sep 27, 2019 at 7:37 PM Bruce Momjian <bruce@momjian.us> wrote:

> On Wed, Sep  4, 2019 at 01:12:35PM +0000, PG Doc comments form wrote:
> > The following documentation comment has been logged on the website:
> >
> > Page: https://www.postgresql.org/docs/11/indexes-unique.html
> > Description:
> >
> > Sometimes it is convenient to create an unique index that considers NULL
> > values equal. Designating a "zero" value for those rows might not be
> > feasible, for example due to a foreign key.
> >
> > The documentation currently only states that unique indexes do not
> consider
> > NULLs equal. It might be good to offer workarounds, like indexing a
> coalesce
> > function, if scans are not the reason for the index, but the uniqueness
> > constraint.
>
> I did write a blog entry about this:
>
>         https://momjian.us/main/blogs/pgblog/2017.html#April_3_2017
>
> Does that help?
>
> --
>   Bruce Momjian  <bruce@momjian.us>        http://momjian.us
>   EnterpriseDB                             http://enterprisedb.com
>
> + As you are, so once was I.  As I am, so you will be. +
> +                      Ancient Roman grave inscription +
>


-- 
- Tuomas

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

<div dir=3D"ltr">That is a nice design. You can create a regular unique ind=
ex where columns(s)s are not null and then filtered index(es) for the cases=
 where some of the unique columns are null.<div><br></div><div>However my p=
oint, specifically, was that if the document in question would have offered=
 alternative solutions, I personally would have been saved from some frustr=
ation=C2=A0and an exercise in bad index design (I had 5 nullables that need=
 uniqueness for the null as well). Maybe it would help someone else.</div><=
/div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">O=
n Fri, Sep 27, 2019 at 7:37 PM Bruce Momjian &lt;<a href=3D"mailto:bruce@mo=
mjian.us">bruce@momjian.us</a>&gt; wrote:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex">On Wed, Sep=C2=A0 4, 2019 at 01:12:35PM +0000, PG=
 Doc comments form wrote:<br>
&gt; The following documentation comment has been logged on the website:<br=
>
&gt; <br>
&gt; Page: <a href=3D"https://www.postgresql.org/docs/11/indexes-unique.htm=
l" rel=3D"noreferrer" target=3D"_blank">https://www.postgresql.org/docs/11/=
indexes-unique.html</a><br>
&gt; Description:<br>
&gt; <br>
&gt; Sometimes it is convenient to create an unique index that considers NU=
LL<br>
&gt; values equal. Designating a &quot;zero&quot; value for those rows migh=
t not be<br>
&gt; feasible, for example due to a foreign key.<br>
&gt; <br>
&gt; The documentation currently only states that unique indexes do not con=
sider<br>
&gt; NULLs equal. It might be good to offer workarounds, like indexing a co=
alesce<br>
&gt; function, if scans are not the reason for the index, but the uniquenes=
s<br>
&gt; constraint.<br>
<br>
I did write a blog entry about this:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"https://momjian.us/main/blogs/pgblog=
/2017.html#April_3_2017" rel=3D"noreferrer" target=3D"_blank">https://momji=
an.us/main/blogs/pgblog/2017.html#April_3_2017</a><br>
<br>
Does that help?<br>
<br>
-- <br>
=C2=A0 Bruce Momjian=C2=A0 &lt;<a href=3D"mailto:bruce@momjian.us" target=
=3D"_blank">bruce@momjian.us</a>&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"=
http://momjian.us" rel=3D"noreferrer" target=3D"_blank">http://momjian.us</=
a><br>
=C2=A0 EnterpriseDB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"http://enterpris=
edb.com" rel=3D"noreferrer" target=3D"_blank">http://enterprisedb.com</a><b=
r>
<br>
+ As you are, so once was I.=C2=A0 As I am, so you will be. +<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 Ancient Roman grave inscription +<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"gmail_signature">- Tuomas</div>

--0000000000006578fa0595924fae--