Ok, thanks. I'll try to get a patch up for it. J
On Tue, Jul 7, 2015 at 3:38 PM, Sudheesh Katkam <[email protected]> wrote: > No nuance. My bad, I did not look into the details of how the parallelizer > arrives at the final value of width using minWidth and maxWidth. So the > method can be safely removed. minWidth > 1 is a sufficient check. > > > On Jul 7, 2015, at 3:26 PM, Jacques Nadeau <[email protected]> wrote: > > > > Agreed. It seems like the same could be accomplished by simply > determining > > whether minWidth is greater than 1. > > > > On Tue, Jul 7, 2015 at 3:24 PM, Jinfeng Ni <[email protected]> > wrote: > > > >> Sudheesh may have better idea. From the code, seems enforceWidth() is > used > >> only in ExcessiveExchangeIdentifier. The purpose is to prevent > >> ExcessiveExchangeIdentifer from removing Exchange operator, when we want > >> the query of distributed system table (memory, threads) to run in > >> distributed mode. > >> > >> select * from sys.memory; > >> > >> > >> > >> On Tue, Jul 7, 2015 at 3:01 PM, Jacques Nadeau <[email protected]> > wrote: > >> > >>> Hey Guys, > >>> > >>> In reviewing GroupScan [1], I noted that we have an enforceWidth method > >> in > >>> addition to getMin and getMax. If we set min == max, wouldn't that > >>> accomplish the same task? Or am I missing a nuance here? It seems > like > >>> the location referenced in the javadoc could just as well look at > whether > >>> getMin() > 1. Thoughts? > >>> > >>> thanks, > >>> Jacques > >>> > >>> [1] > >>> > >>> > >> > https://github.com/apache/drill/blob/master/exec/java-exec/src/main/java/org/apache/drill/exec/physical/base/GroupScan.java#L61 > >>> > >> > >
