My current patch (https://reviews.apache.org/r/24778/) is adding window function support by only supporting unbounded preceding and current now window functions.
I'm re-using all the existing drill aggregation functions, and added a new WindowPOP physical operator and Window logical operator, that generates code to perform the window function and outputing the partial aggregate result on each row processed. I've also added drill optiq physical rel for windowing (DrillWindowRel) that converts a Optiq Window rel into a series of Drill physical operators, and currently adding a sort for all the window partitioned by fields before each window pop. The next phase is to really support all configurable offsets configurations, but by adding a new window aggregate functions definitions and function scopes, and able to generate code specifically for window aggregate functions. The first phase is to start implementing these functions: lead rank lag percentile I have a WIP branch here: https://github.com/tnachen/incubator-drill/commit/58f708d59b7d1b34059e98d96110f33aefe7c0e9 I've already added a function rewrite (adding a "_win")in Optiq layer to use window specific aggregate functions, and starting to define what the function will look like and some modification in the code gen. I haven't get the time to come back to it yet, but will be great to rebase on master again and start getting a new window functions and new function scope plugged all the way, and also change the WindowFramer to generate code based on the window configuration. Tim On Mon, Sep 15, 2014 at 9:57 AM, Jacques Nadeau <[email protected]> wrote: > Tim, can you provide everybody an overview of what functionality your > current patch provides? Maybe we can break remaining requirements into > tasks and have everyone work on a piece to get completed soon. > > Thanks > Jacques > On Sep 14, 2014 7:06 AM, "Timothy Chen" <[email protected]> wrote: > >> Hi Matt, >> >> I'm also working on window functions (Yash is interested helping) and we >> should work together. I already have a first patch that provides a physical >> operator but now going to build on top of it to provide more flexible >> ground work for different window functions and offets configurations. >> >> Tim >> >> Sent from my iPhone >> >> > On Sep 14, 2014, at 7:53 AM, Matt Burgess <[email protected]> wrote: >> > >> > I'm looking at some windowing functions (starting with rank functions >> like row_number, rank, and dense_rank) right now, not sure if those count >> as analytic functions for this discussion or not... >> > >> > Regards, >> > Matt >> > >> > Sent from my iPhone >> > >> >> On Sep 14, 2014, at 2:28 AM, Ted Dunning <[email protected]> wrote: >> >> >> >> Uli, >> >> >> >> Which analytics functions do you mean? >> >> >> >> Does this impression of high priority mean that you are willing to work >> on >> >> these analytics functions? >> >> >> >> Michael is offering to implement these functions for his own >> edification. >> >> That is a great thing. Could you provide some guidance about which >> >> functions you think would be more useful with some examples of why you >> >> think so? >> >> >> >> >> >> >> >> >> >> >> >> >> >>> On Sat, Sep 13, 2014 at 1:33 PM, Uli Bethke <[email protected]> >> wrote: >> >>> >> >>> My personal opinion is that analytic functions should take a much >> higher >> >>> priority. No analytics database engine can live without these. In my >> >>> opinion anything that you can do with ROLLUP/CUBE you can do with >> analytic >> >>> functions while the opposite is not true. >> >>> >> >>> Uli >> >>> >> >>> >> >>>> On 13/09/2014 18:57, Michael Johnson wrote: >> >>>> >> >>>> For an advanced databases class project, I'm looking at adding CUBE >> and >> >>>> ROLLUP operators to Drill. (I'll be working up to that by trying out >> some >> >>>> smaller changes first to get a better understanding of Drill's code.) >> >>>> >> >>>> Does this sound like a feature that you might want to incorporate into >> >>>> Drill? Any other thoughts about this idea? >> >>>> >> >>>> Michael >> >>> >>
