> On Mon, 23 Jul 2018 at 10:38, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> wrote:
>
> On Fri, Jul 20, 2018 at 3:13 AM, Dmitry Dolgov <9erthalion6@gmail.com> wrote:
> >
> > It's of course wrong, it's going to be O(max(m, n)) as you said, but
> > the point is still valid - if we have partitions A1, A2 from one side
> > and B1, ..., BN on another side, we can skip necessary the
> > partitions from B that are between e.g. A1 and A2 faster with
> > binary search.
>
> That's possible only when there is no default partition and the join
> is an inner join. For an outer join, we need to include all the
> partitions on the outer side, so we can't just skip over some
> partitions. In case of a default partition, it can take place of a
> missing partition, so we can't skip partitions using binary search.
But in this case I described above (when we have a partition A3 on one side,
and another matching partition B3 from other side, but separated by some other
partitions, e.g. B1, B2) it means that we will merge A3 with a default
partition from other side without actually needing that, am I right? In this
sense it's an overhead out of nothing.
> 1. those cases are rare enough that we can ignore those right now. How
> many times we would encounter the case you have quoted, for example?
> Usually the ranges will be continuous only differing in the first or
> last partition e.g time-series data.
Well, unfortunately, I don't have enough context to discuss whether it's rare
or not.