Re: A new proof of the superiority of set oriented approaches: numerical/time serie linear interpolation

"Cimode" <cimode_at_hotmail.com> wrote in message news:1178053090.386865.126950_at_h2g2000hsg.googlegroups.com...
> On 30 avr, 13:42, "David Cressey" <cresse..._at_verizon.net> wrote:
>> "Cimode" <cim..._at_hotmail.com> wrote in message
> [Snipped]
>
>> > Not only. I have not talked about *order*. Set oriented approaches
>> > are totally *order insensitive* in the sense they never require some
>> > kind of order as a prerequisite.
>>
>> I am not sure I understand your point. If I got it right, I'd like to
>> suggest that procedural oriented thinkers like to superimpose an order
>> requirement on the actual requirements in order to force a strategy that
>> they know (rightly or wrongly) to be superior to the one chosen by the
>> optimizer in the absence of ordering directives.
>>
> I realize I missed that point but the answer is yes. That's what I
> meant to say.
>
> I would also add to the bill of procedurally inclined programmer the
> *physical bias* to create overhead objects (temp tables, additional
> columns) in order to meet the requirement of a procedural approach.
> We have one example here. For instance, the immediate instinct of
> dear Brian was to create additional columns and objects (+ unecessary
> operation) where none was in fact necessary. Procedural approaches
> produce both physical AND logical overhead. What can be done in 3 set
> operations may require much more operations in procedural mindset (out
> of itterations I don't count).
>

Have you actually tried what I suggested? How can you possibly argue that it produces physical and logical overhead without proof. In an earlier post, I offered what I think is a solid theoretical foundation for the thought process that triggered my immediate instinct: Multiple self-joins can often be eliminated with a single iterative pass through the data. Your solution has six--count 'em, SIX--self joins. To make things worse, four of them are theta-joins! So yes, my immediate instinct was to eliminate those self-joins. As a bonus, your solution also includes an aggregate, which I immediately saw could be computed during the same pass through the data, eliminating yet another optimizer step.

Eliminating self-joins is beneficial regardless of the implementation. Have you even looked at my earlier post? You didn't respond. From a logical standpoint, my suggestion actually takes fewer operations, since there is only one inner equijoin and one relation-valued function instead of four outer theta-joins, an outer equijoin, an inner equijoin and an aggregate. There is no doubt that a procedural approach involves additional statements, but it is not *always* the case that that means that the system will have to do more work, or take more time, or use more resources.

> [Snipped]
>
>
Received on Thu May 03 2007 - 03:44:26 CEST