Re: Rangejoin rebased

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Rangejoin rebased
Дата
Msg-id CANP8+jJxwUGXV72ApkHKadjj+RuG+SnNdSY-oXo5GzPDNtOMeg@mail.gmail.com
обсуждение исходный текст
Ответ на Rangejoin rebased  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: Rangejoin rebased  (Jeff Davis <pgsql@j-davis.com>)
Список 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 по дате отправления:

Предыдущее
От: Ryan Murphy
Дата:
Сообщение: Re: Challenges preventing us moving to 64 bit transaction id (XID)?
Следующее
От: Ryan Murphy
Дата:
Сообщение: Re: Challenges preventing us moving to 64 bit transaction id (XID)?