Re: A new proof of the superiority of set oriented approaches: numerical/time serie linear interpolation
Date: Tue, 01 May 2007 02:51:23 GMT
Message-ID: <LWxZh.162$Pg4.2316_at_ursa-nb00s0.nbnet.nb.ca>
David Cressey wrote:
> "Bob Badour" <bbadour_at_pei.sympatico.ca> wrote in message
> news:6mcZh.29368$PV3.313454_at_ursa-nb00s0.nbnet.nb.ca...
>
>>David Cressey wrote: >> >> >>>"Brian Selzer" <brian_at_selzer-software.com> wrote in message >>>news:jy5Zh.4247$uJ6.3542_at_newssvr17.news.prodigy.net... >>> >>> >>>>"Cimode" <cimode_at_hotmail.com> wrote in message >>>>news:1177863186.258396.136950_at_y5g2000hsa.googlegroups.com... >>>> >>>> >>>>>On 29 avr, 16:21, "Brian Selzer" <b..._at_selzer-software.com> wrote: >>>>> >>>>> >>>>>>I would have done it differently. I would have used a cursor to >>> >>>generate >>> >>> >>>>>[Snipped] >>>>>I respectfully think you miss the point of the entire thread. >>>>>Thinking procedurally (use of cursors) is inherently inferior to set >>>>>oriented approaches independently of a specific implementation and >>>>>regardless of how one defines performance as response time, ability to >>>>>run well in concurrent query environment and so forth. >>>>> >>>> >>>>You're right. As a rule, set-based thinking is superior to procedural >>>>thinking. But there are times when it becomes necessary to break the >>> >>>rules. >>> >>> >>>>It is critical to think procedurally in order to understand the
>
> execution
>
>>>>plans that an optimizer produces. >>> >>>This is correct, but it largely misses the point. One thinks about how
>
> the
>
>>>optimizer does its job in the (hopefully rare) cases where the
>
> optimizer's
>
>>>output is materially suboptimal. >>> >>>My own experience some 15 years ago with DEC Rdb is a case in point.
>
> The
>
>>>DEC optimizer was so good that, in most cases, it was simply not
>
> necessary
>
>>>to think about how it worked. That allowed the query designer (and for
>
> that
>
>>>matter the database designer) to focus on the other aspects of quality >>>without sacrificing much in the way of speed. >>> >>> >>> >>>>Consider a merge join: both inputs are >>>>sorted, and then a single pass is made through each result--similar to
>
> an
>
>>>>old COBOL program that updates a master file from a transaction file.
>
> If
>
>>>>you don't understand what each step in an execution plan does and how it >>>>works, then how can you possibly optimize a query? >>>> >>>>When it becomes clear that an iterative approach could eliminate several >>>>self-joins, thus decreasing the duration that locks are held, reducing
>
> the
>
>>>>impact on temporary storage and decreasing cpu utilization, then it
>
> might
>
>>>be >>> >>> >>>>a good idea to break the rules. You mentioned that switching from a >>> >>>poorly >>> >>> >>>>designed procedural solution to one that is set-based dropped the time
>
> it
>
>>>>took for the process to run from 10 hours to 30 minutes. That's great!
>
> I
>
>>>>merely suggest that reintroducing a cursor to eliminate the several >>>>self-joins in your solution might further decrease the time it would
>
> take
>
>>>>for the process to run--without any negative impact on concurrency or >>>>overall performance. >>> >>>All of these comments should lead to one conclusion: one engages in
>
> this
>
>>>sort of analysis when one is intent on writing a better optimizer, or
>
> when
>
>>>coming up with a workaround in the case of a deficient optimizer. Not
>
> in
>
>>>the case of using a good optimizer to good effect. >> >>David, please don't be too dismayed when I say: Lately, I have been >>liking your answers better and better.
>
> Turn about is fair play. Lately I've been liking your tone better and
> better. It's possible to rebut without berating, and you seem to have been
> doing precisely that.
The interesting thing is: I have not changed my methods one bit. The only thing that changed recently is the material I have to work with.
The snake-oil salesmen, cranks, trolls and other self-aggrandizing ignorants have found their way to the bottom of my killfile. The seemingly compulsive replies to their nonsense have stopped--at least for the moment. For the first time in a long while, I am actually seeing some signal in the newsgroup. While the noise is still there, I have it filtered.
It is nice to see Vadim has some time for the newsgroup again. I am a little concerned that we are seeing less of Marshall, Jan, Walt and Jim. I assume they are busy right now, and I hope we see more of them again in the future. Received on Tue May 01 2007 - 04:51:23 CEST