db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manish Khettry <manish_khet...@yahoo.com>
Subject Re: [jira] Commented: (DERBY-883) Enhance GROUP BY clause to support expressions instead of just column references.
Date Wed, 05 Jul 2006 21:05:39 GMT

Actually, I'm still working on it and have got it
working for the most part.

I still need to cleanup the code, add more error
messages, more compile time checks and tests (all the
fun stuff) before its ready for checkin. What is the
timeframe for getting things into 10.2?

m
--- Satheesh Bandaram <bandaram@gmail.com> wrote:

> Hi Manish,
> 
> Do you have any updates on your progress to share
> with us? It seemed you
> had a good design to support GROUP BY expressions
> last time it was
> discussed. Would this be ready in time for 10.2? I
> have itch to see this
> issue progress and can help.
> 
> Even if you have basic framework for rewriting the
> query, but haven't
> implemented "matching" facility, I would suggest you
> contribute that if
> ready. You could add *isEquivalent()* function that
> simply returns FALSE
> except for simple column references. Then it should
> be possible to
> incrementally allow specific expression "matching"
> by either yourself or
> others in the community.
> 
> Thanks,
> Satheesh
> 
> Manish Khettry wrote:
> 
> > Here is what I think needs to be implemented
> >
> > First, an expression "matching" facility. The
> first cut can be
> > restricted to looking at two expressions and
> detecting if they are the
> > "same"-- by same, I mean, they will evaluate to
> the same value at
> > runtime. Thus the expression "f()" is not the same
> as "f()". (I don't
> > see a way in the derby docs to declare a function
> as "deterministic"--
> > is that correct?)
> >
> > Second, the group by binding/validation code will
> need to lose
> > assumptions about grouping expressions being
> columns. We'll also have
> > to do a little query rewrite (I'm guessing) to
> replace references to
> > the grouping expressions in the having/select
> clause.
> >
> > When we have this functionality ofcourse, as you
> suggest in your
> > email, we'll look into allowing subexpressions and
> such.
> >
> > As far as the first step goes, I plan on adding a
> function to the base
> > class (ValueNode).
> >
> > protected boolean isEquivalent(ValueNode other)
> > {
> >   return false;
> > }
> >
> > and having each subclass override this method and
> ofcourse do the
> > right thing.
> >
> > I'll have to spend time looking at the ValueNode
> hierarchy and see
> > what the correct behavior for "isEquivalent" is
> going to be for each
> > class.
> >
> > Just wanted to swing this proposal by people more
> familiar with the
> > code. If you see anything wrong in this proposal,
> let me know. I'll
> > probably start on it in a day or two.
> >
> > cheers
> > Manish
> >
> > On 5/23/06, *Satheesh Bandaram*
> <bandaram@gmail.com
> > <mailto:bandaram@gmail.com>> wrote:
> >
> >     Manish, good research. I think you are on the
> right track. Derby
> >     already rewrites GROUP BY clause into select
> subquery so that
> >     HAVING clause can be converted into a WHERE
> clause on top of
> >     select subquery, with aggregate references
> converted into simple
> >     columnReferences. Search for groupByList in
> sqlgrammar.jj. While
> >     this rewrite makes implementation easier
> without any performance
> >     penality, it does confuse a few query
> resolutions. See DERBY-280.
> >     (
> http://issues.apache.org/jira/browse/DERBY-280)
> >
> >     So, I think both the approaches below are
> essentially same thing,
> >     because of current Derby rewrite. This rewrite
> could make
> >     implementing this feature easier, like you
> said. Most of the work
> >     seems to be in the compile phase.
> >
> >     To start with, you could implement simple
> expression matching,
> >     which only finds exact matches:
> >
> >     Select day(ts), count(*) from timeStampTab
> group by day(ts) having
> >     day(ts) = 1
> >
> >     Then it can be expanded to support proper
> sub-expressions.
> >
> >     Select (a+b)+c, count(*) from intTab group by
> a+b
> >
> >     Note that DB2 and Oracle don't seem to have
> fancy expression
> >     matching, rejecting this:
> >
> >     Select b+a, count(*) from intTab group by a+b
> >
> >     so, Derby expression matching can be simple
> matching algorithm, to
> >     start with. Good thing with this new feature
> is that it can be
> >     expanded incrementally, without breaking
> existing or intermediate
> >     stage queries.
> >
> >     Does that help?
> >
> >     Satheesh
> >
> >
> >     On 5/20/06, *Manish Khettry *
> <manish.khettry@gmail.com
> >     <mailto:manish.khettry@gmail.com>> wrote:
> >
> >         Thanks Alex and Satheesh, that does
> clarify things quite a bit.
> >
> >         I spent some time looking at the
> GroupedAggregateResultSet and
> >         I have the feeling that atleast on the
> execution side of
> >         things not much will have to change. A
> grouped aggregate RS
> >         already sits on top of a ProjectRestrictRS
> and if we can have
> >         the prRS evaluate the expressions we are
> grouping on, the
> >         existing logic should work without any (or
> perhaps minimal)
> >         changes. It is on the compilation side of
> things that this is,
> >         err rather hairy :) Someone should correct
> me if I'm missing
> >         something here or simplifying things.
> >
> >         The other approach is to rewrite the query
> to use a select
> >         subquery like Satheesh suggested. Perhaps
> this is a better way
> >         to go. Any thoughts on which approach is
> better?
> >
> >
> >
> >         On 5/18/06, *Alex Miller*
> <amiller@metamatrix.com
> >         <mailto:amiller@metamatrix.com>> wrote:
> >
> >             No, we don't go quite that far. 
> Because most dbs support
> >             group by expressions, we haven't
> needed to implement this. 
> >
> >            
>
------------------------------------------------------------------------
> >             *From:* Satheesh Bandaram
> [mailto:bandaram@gmail.com
> >             <mailto:bandaram@gmail.com>]
> >             *Sent:* Thursday, May 18, 2006 2:16 PM
> >
> >             *To:* derby-dev@db.apache.org
> <mailto:derby-dev@db.apache.org>
> >             *Subject:* Re: [jira] Commented:
> (DERBY-883) Enhance GROUP
> >             BY clause to support expressions
> instead of just column
> 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Mime
View raw message