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:1177913268.965918.63520_at_p77g2000hsh.googlegroups.com...
> On 29 avr, 21:29, "David Cressey" <cresse..._at_verizon.net> wrote:
> > "Cimode" <cim..._at_hotmail.com> wrote in message
> [Snipped]
> > The point I got from your remarks is that set oriented approaches are
> > superior, not principally due to run times, but due to inherent
solidity of
> > the code. The gap between intent and expression of algorithm is often
much
> > less with set oriented approaches, and I believe you have illustrated
this
> > in the case in point.
> 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.

This reminds me of one of the rare cases where I spotted a blind spot in the DEC optimizer.

I found a case where

select ... group by B, A order by A, B

ran about 10 times as fast as

select ... group by A, B order by A, B.

It turns out that (at least at that time) the strategy generator part of the optimizer didn't know that group by B, A and group by A, B are logically equivalent, and therefore never submitted the best strategy for cost analysis.

Meanwhile, my technical counterparts on the programming side were objecting to

select ... group by A, B order by A, B

because, according to them, the order by clause was redundant, and therefore a waste of time.

I guess I profile people based on their usage as well as Joe Celko or Bob Badour. In this case, anyone who strains to omit an "order by" clause based on response time rather than requirements, or based on a side effect of "group by", is still thinking "how" rather than "what". At least that's my take.

> > Many times, those who wish to cling to procedural ways of doing things
latch
> > onto processing time as their reason for rejecting a set oriented
approach.
> Until they have slow disks and can not solve CPU bottlenecks anymore
> through more CPU power. A recurring problem in modern systems.
>
> [Snipped]
> > I've seen the same "speed" arguments used for avoiding views, and
avoiding
> > logical data independence generally. Also used to defend the "one big
> > table" design as opposed to normalized, or even mostly normalized
design.
> If you ask me, I think the *speed obsession* comes from the good deal
> between poor software editors and hardware manufacturers. The rest is
> just a consequence of cookbook approach.
>

I got out of the field before the following became prevalent, but judging from inputs in this newsgroup and several other forums, speed requirements are increasingly being defined as "faster than our comptitors, however fast that is." Back in the 90s, I dealt with people whose speed requirements were relatively crisp: "the response must come in in 7 seconds, 90% of the time". If you came up with a solution that satisfied this speed requirement, you DIDN'T spend the next evening of weekend figuring out how to do it in 3 seconds.

When I used the term "materially suboptimal" a few responses back, I was trying to condense the above thought into two words. I'm not sure I succeeded. Received on Mon Apr 30 2007 - 13:42:49 CEST