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-19 08:25:30
Message-ID: CANP8+jJrZhcucpcuZ3AWGwZ_My=0BLVG0pfqfPwkP7BQhFzZow@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 17 January 2018 at 05:49, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> On Wed, Jan 10, 2018 at 7:49 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> Do we optimize for TIMESTAMP <@ RANGE as well?
>
> Not currently. It requires a little extra complexity because empty
> ranges will match anything and need special handling.

TIMESTAMP <@ RANGE is arguably more important than RANGE && RANGE

Trying to cast timestamp to range to make that work is a bit hokey

If the problem is just empty ranges, it seems like we should do that here also.

I'd be happy with the optimization only working if ranges are provably
non-empty, e.g. CHECK (NOT isempty(col))
Or perhaps we need non-empty types: e.g. tsrangene

--
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 Kyotaro HORIGUCHI 2018-01-19 08:26:46 Re: [HACKERS] [PATCH] Improve geometric types
Previous Message Michael Paquier 2018-01-19 08:08:56 Re: PATCH: Configurable file mode mask