>>Do you have performance numbers for the testcase ?
Yes. In my testcase, a split of 256M join with 100K is now taking more than 5 hours. (join value can be ignored, so 256M and 100K are about pure key size).
And the 'map join size' should not be determined only by the big size ( eg. 256M). The small size is more important in this case.
The point is that KEY1 ("256M join 100K") should use a much smaller split size than KEY2 ("256M join 1K"). The problem here is that we are now doing KEY1 and KEY2 in a same job. So if we choose a split size according to KEY1, it maybe a bit small for KEY2.
If we are going to choose to use bucket join for the followup mapjoin job. We will be able to choose split size independently for different keys (because we are doing that in different jobs).