Re: Rangejoin rebased

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Rangejoin rebased
Date: 2018-01-23 10:04:08
Message-ID: CANP8+jK6u=aEXU6OM12v8r-tqQ_yC-T3BbrQRC57gBaOBmB+SA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 23 January 2018 at 05:08, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> On Fri, Jan 19, 2018 at 2:07 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> err... that isn't correct. An empty range matches nothing, so can be
>> ignored in joins.
>>
>> So probably best to explain some more, please.
>
> The semantics of R1 @> R2 will return true if R1 is a non-NULL range
> and R2 is empty.
>
> It's set semantics, and all sets contain the empty set.

Understood

> But I understand @> is an important case so I am looking into it.

Perhaps we are misunderstanding each other

TIMESTAMP <@ RANGE1 doesn't match if RANGE1 is empty
and that is the most important case

RANGE OP RANGE is important also. It would be useful for OP to be more
than just &&

It's certainly weird that R1 @> EMPTY is true, but R1 && EMPTY is not.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2018-01-23 10:22:37 Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning
Previous Message Kyotaro HORIGUCHI 2018-01-23 09:50:00 Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least 9.5)?