Re: [GENERAL] btree gist indices, null and open-ended tsranges

[Adrian Klaver]

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
>>  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.kla...@aklaver.com


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] btree gist indices, null and open-ended tsranges

[Chris Withers]

On 01/12/2016 12:12, Francisco Olarte wrote:

On Thu, Dec 1, 2016 at 12:56 PM, Chris Withers  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


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] btree gist indices, null and open-ended tsranges

[Francisco Olarte]

Hi Chris:

On Thu, Dec 1, 2016 at 12:56 PM, Chris Withers  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.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] btree gist indices, null and open-ended tsranges

[Chris Withers]

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


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general