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 Thu, 06 Jul 2006 21:21:06 GMT
Satheesh,

Yes, my current changes accept a "additiveExpression"
in the parser. The binding step checks that the select
list has no column references outside of aggregates or
grouping expressions and the query rewrite also seems
to be working atleast with simple arithmetic
expressions.

I need to look at error checking and special cases
like functions as well as write tests. I'm leaning
towards writing a JUnit test case (using BooleanTest)
as a model. Any thoughts on this would be appreciated.

End of july sounds doable. I hope to be done next week
unless I run into problems.



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

> This is great... Looks like you are close to
> finishing up. Do your current
> changes support expressions and function calls in
> GROUP BY? You had raised
> questions about whether function calls could be in
> GROUP BY... because Derby
> functions can not be defined invariant yet.
> 
> I think end of July is the current timeframe for
> 10.2 features, with Aug 10
> being code freeze for first Release candidate. But I
> have been out for a
> month, so not sure if these dates may have changed
> recently.
> 
> Satheesh
> 
> On 7/5/06, Manish Khettry <manish_khettry@yahoo.com>
> wrote:
> >
> >
> > 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
> 
=== message truncated ===


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

Mime
View raw message