gt;> >>current
>> >> >system. When vectorization is turned on, we will have a validation
>> >>step to
>> >> >make sure the given query is supported on the vectorization path
>> >>otherwise
>> >> >it will fall back to current co
Although, we intend to follow commit then review policy on the branch
> >> >for
> >> >speed of development, each patch will have an associated jira and will
> >>be
> >> >available for review and feedback.
> >> >
> >> >thanks
> >&
lthough, we intend to follow commit then review policy on the branch
>> >for
>> >speed of development, each patch will have an associated jira and will
>>be
>> >available for review and feedback.
>> >
>> >thanks
>> >jitendra
>> >
>> >O
- it can be a for
> >> loop to
> >> start with ? I think it will be very difficult to merge it back if we
> >> diverge on this.
> >> I would recommend starting with simple interfaces for operators and then
> >> plugging them
> >> in slowly inst
or operators and then
>> plugging them
>> in slowly instead of a new branch, unless this approach is extremely
>> difficult.
>>
>>
>> Thanks,
>> -namit
>>
>> On 4/3/13 1:52 AM, "Jitendra Pandey" wrote:
>>
>> >Hi Folks,
>>
e:
>
> >Hi Folks,
> > I want to propose for creation of a separate branch for HIVE-4160
> >work. This is a significant amount of work, and support for very basic
> >functionality will need big chunks of code. It will also take some time to
> >stabilize and test. A s
interfaces for operators and then
plugging them
in slowly instead of a new branch, unless this approach is extremely
difficult.
Thanks,
-namit
On 4/3/13 1:52 AM, "Jitendra Pandey" wrote:
>Hi Folks,
> I want to propose for creation of a separate branch for HIVE-4160
Hi Folks,
I want to propose for creation of a separate branch for HIVE-4160
work. This is a significant amount of work, and support for very basic
functionality will need big chunks of code. It will also take some time to
stabilize and test. A separate dev branch will allow us to do this work
