Re: Rangejoin rebased - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Rangejoin rebased
Date
Msg-id CANP8+jJxwUGXV72ApkHKadjj+RuG+SnNdSY-oXo5GzPDNtOMeg@mail.gmail.com
Whole thread Raw
In response to Rangejoin rebased  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Rangejoin rebased
List pgsql-hackers
On 29 December 2017 at 18:25, Jeff Davis <pgsql@j-davis.com> wrote:
> New rangejoin patch attached.
>
> I had previously attempted to make this work well for multiple range
> join keys, but this patch implements single rangejoin keys only, and
> the rest of the rangejoin clauses are effectively just rechecks. I
> believe it can be made effective for multiple rangejoin keys, but at
> the cost of additional complexity which is neither justified nor
> implemented at this point.

For this to be useful, it needs to include some details of how to use
it when people have NOT used range datatypes in their tables.

If we can see some examples with StartDate and EndDate cast to a
tzrange, plus some "don't write it like this" anti-patterns that would
help.

We can then make it clear that this is a huge performance benefit for
these important cases.

Just to emphasise why we want this, it might be better for the EXPLAIN
to say "Time Range Join" when the ranges being joined are Time Ranges,
and for other cases to just say "Range Join". The use of the word
Merge doesn't help much there.

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


pgsql-hackers by date:

Previous
From: Ryan Murphy
Date:
Subject: Re: Challenges preventing us moving to 64 bit transaction id (XID)?
Next
From: Ryan Murphy
Date:
Subject: Re: Challenges preventing us moving to 64 bit transaction id (XID)?