Re: GROUP BY

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Sat, 19 May 2007 16:21:03 -0300
Message-ID: <464f4dd6$0$4052$9a566e8b_at_news.aliant.net>


Marshall wrote:

> On May 19, 7:38 am, "Brian Selzer" <b..._at_selzer-software.com> wrote:
>

>>"Marshall" <marshall.spi..._at_gmail.com> wrote in message
>>
>>
>>>So: what *about* that extended extend?
>>
>>>Extend is a particular form of join, yes? So perhaps we
>>>ought to apply generators with join?
>>
>>>I note that there is an issue with regards to the uniqueness
>>>of values produced by a generator. It's not clear to me if
>>>that ought to be required or not. If it's required, it's not clear
>>>to me if it's enforceable, since I don't see how to prove uniqueness.
>>
>>>If the outputs of the generator aren't unique, then we have
>>>a function from a tuple to a bag, which also matches the
>>>fact that aggregate functions are functions from a bag to
>>>a tuple.
>>
>>I don't agree with this.  An aggregate function iterates over a relation,
>>taking a projection of each tuple to find the values required to calculate
>>the result.

>
> Well, that's not really incompatible with what I wrote. You've given
> an operational description; mine is more ... mathematical? abstract?

How about "Correct" ?

Project a tuple? I suppose one can project a point in an n-space into another space. But is that really how one finds the values required to calculate anything? After one projects, most of the values required for the calculation are gone.

> Yours is maybe a bit narrow, though, because by being so specific
> about the algorithm to implement aggregation, you've eliminated
> the possibility for parallelization.

You are making more sense out of what he wrote than is even there. I suggest you stop trying so hard to make sense out of nonsense.

>>While it is convenient to visualize the collection of values
>>for an attribute in a relation as a bag, it should not be ignored that any
>>particular combination of values in that bag depends solely on the existence
>>of a particular *set* of tuples.

>
> Um, I don't see how. Anyway, we can certainly consider sum() in
> the abstract. It is a function taking a bag of numbers to a single
> number.
> In some languages it is considered to take a list, but that too is
> overspecifying, since order is not significant.

Whether order is significant depends on the base operation. Addition is associative and commutative, but not all operations are.

I reiterate: You are trying too hard to make sense out of nonsense.

[snip] Received on Sat May 19 2007 - 21:21:03 CEST

Original text of this message