Обсуждение: btree gist indices, null and open-ended tsranges
Hi All, Working with the exclude constraint example from https://www.postgresql.org/docs/current/static/rangetypes.html: CREATE EXTENSION btree_gist; CREATE TABLE room_reservation ( room text, during tsrange, EXCLUDE USING GIST (room WITH =, during WITH &&) ); So, first observation: if I make room nullable, the exclude constraint does not apply for rows that have a room of null. I guess that's to be expected, right? Next question: if lots of rows have open-ended periods (eg: [, 2010-01-01 15:00) or [2010-01-01 14:00,)), how does that affect the performance of the btree gist index backing the exclude constraint? cheers, Chris
Hi Chris: On Thu, Dec 1, 2016 at 12:56 PM, Chris Withers <chris@simplistix.co.uk> wrote: > So, first observation: if I make room nullable, the exclude constraint does > not apply for rows that have a room of null. I guess that's to be expected, > right? I would expect it, given: n=> select null=null, null<>null, not (null=null); ?column? | ?column? | ?column? ----------+----------+---------- | | (1 row) Those are nulls, BTW: n=> select (null=null) is null, (null<>null) is null, (not (null=null)) is null; ?column? | ?column? | ?column? ----------+----------+---------- t | t | t (1 row) I.e., the same happens with a nullable unique column, you can have one of each not null values and as many nulls as you want. SQL null is a strange beast. Francisco Olarte.
On 01/12/2016 12:12, Francisco Olarte wrote: > On Thu, Dec 1, 2016 at 12:56 PM, Chris Withers <chris@simplistix.co.uk> wrote: >> So, first observation: if I make room nullable, the exclude constraint does >> not apply for rows that have a room of null. I guess that's to be expected, >> right? > > I would expect it, given: > > n=> select null=null, null<>null, not (null=null); > ?column? | ?column? | ?column? > ----------+----------+---------- > | | > (1 row) > > Those are nulls, Yes, it's a shame psql has the same repr for null and empty-string ;-) > n=> select (null=null) is null, (null<>null) is null, (not (null=null)) is null; > ?column? | ?column? | ?column? > ----------+----------+---------- > t | t | t > (1 row) > > I.e., the same happens with a nullable unique column, you can have one > of each not null values and as many nulls as you want. > > SQL null is a strange beast. Sure, I think that was the answer I was expecting but not hoping for... However, my "next question" was the one I was really hoping for help with: Working with the exclude constraint example from https://www.postgresql.org/docs/current/static/rangetypes.html: CREATE EXTENSION btree_gist; CREATE TABLE room_reservation ( room text, during tsrange, EXCLUDE USING GIST (room WITH =, during WITH &&) ); Next question: if lots of rows have open-ended periods (eg: [, 2010-01-01 15:00) or [2010-01-01 14:00,)), how does that affect the performance of the btree gist index backing the exclude constraint? Tom Lane made a comment on here but never followed up with a definitive answer. Can anyone else help? cheers, Chris
On 12/11/2016 11:34 PM, Chris Withers wrote: > On 01/12/2016 12:12, Francisco Olarte wrote: >> On Thu, Dec 1, 2016 at 12:56 PM, Chris Withers >> <chris@simplistix.co.uk> wrote: >>> So, first observation: if I make room nullable, the exclude >>> constraint does >>> not apply for rows that have a room of null. I guess that's to be >>> expected, >>> right? >> >> I would expect it, given: >> >> n=> select null=null, null<>null, not (null=null); >> ?column? | ?column? | ?column? >> ----------+----------+---------- >> | | >> (1 row) >> >> Those are nulls, > > Yes, it's a shame psql has the same repr for null and empty-string ;-) test=# select NULL; ?column? ---------- (1 row) test=# \pset null 'NULL' Null display is "NULL". test=# select NULL; ?column? ---------- NULL (1 row) > >> n=> select (null=null) is null, (null<>null) is null, (not >> (null=null)) is null; >> ?column? | ?column? | ?column? >> ----------+----------+---------- >> t | t | t >> (1 row) >> >> I.e., the same happens with a nullable unique column, you can have one >> of each not null values and as many nulls as you want. >> >> SQL null is a strange beast. > > Sure, I think that was the answer I was expecting but not hoping for... > > However, my "next question" was the one I was really hoping for help with: > > Working with the exclude constraint example from > https://www.postgresql.org/docs/current/static/rangetypes.html: > > CREATE EXTENSION btree_gist; > CREATE TABLE room_reservation ( > room text, > during tsrange, > EXCLUDE USING GIST (room WITH =, during WITH &&) > ); > > Next question: if lots of rows have open-ended periods > (eg: [, 2010-01-01 15:00) or [2010-01-01 14:00,)), how does that affect > the performance of the btree gist index backing the exclude constraint? > > Tom Lane made a comment on here but never followed up with a definitive > answer. Can anyone else help? > > cheers, > > Chris > > -- Adrian Klaver adrian.klaver@aklaver.com
On 12/12/2016 14:33, Adrian Klaver wrote: > On 12/11/2016 11:34 PM, Chris Withers wrote: >> On 01/12/2016 12:12, Francisco Olarte wrote: >>> On Thu, Dec 1, 2016 at 12:56 PM, Chris Withers >>> <chris@simplistix.co.uk> wrote: >>>> So, first observation: if I make room nullable, the exclude >>>> constraint does >>>> not apply for rows that have a room of null. I guess that's to be >>>> expected, >>>> right? >>> >>> I would expect it, given: >>> >>> n=> select null=null, null<>null, not (null=null); >>> ?column? | ?column? | ?column? >>> ----------+----------+---------- >>> | | >>> (1 row) >>> >>> Those are nulls, >> >> Yes, it's a shame psql has the same repr for null and empty-string ;-) > > test=# select NULL; > ?column? > ---------- > > (1 row) > > test=# \pset null 'NULL' > Null display is "NULL". > > test=# select NULL; > ?column? > ---------- > NULL > (1 row) Sure, so perhaps the default should change? Of course, no-one has yet offered anything on the question I was really hoping for help with: >> Working with the exclude constraint example from >> https://www.postgresql.org/docs/current/static/rangetypes.html: >> >> CREATE EXTENSION btree_gist; >> CREATE TABLE room_reservation ( >> room text, >> during tsrange, >> EXCLUDE USING GIST (room WITH =, during WITH &&) >> ); >> >> Next question: if lots of rows have open-ended periods >> (eg: [, 2010-01-01 15:00) or [2010-01-01 14:00,)), how does that affect >> the performance of the btree gist index backing the exclude constraint? >> >> Tom Lane made a comment on here but never followed up with a definitive >> answer. Can anyone else help? cheers, Chris