> On Mon, 23 Jul 2018 at 10:38, Ashutosh Bapat > <ashutosh.ba...@enterprisedb.com> wrote: > > On Fri, Jul 20, 2018 at 3:13 AM, Dmitry Dolgov <9erthali...@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.
