Re: A new proof of the superiority of set oriented approaches: numerical/time serie linear interpolation
Date: Fri, 04 May 2007 12:27:54 GMT
Message-ID: <eFF_h.7202$rO7.3983_at_newssvr25.news.prodigy.net>
"Cimode" <cimode_at_hotmail.com> wrote in message
news:1178260494.811737.293620_at_y5g2000hsa.googlegroups.com...
> On 4 mai, 02:35, "Brian Selzer" <b..._at_selzer-software.com> wrote:
>> "Cimode" <cim..._at_hotmail.com> wrote in message
>>
>> news:1178221012.371056.145700_at_u30g2000hsc.googlegroups.com...
>>
>>
>>
>> > On 3 mai, 21:04, "Brian Selzer" <b..._at_selzer-software.com> wrote:
>> >> "Cimode" <cim..._at_hotmail.com> wrote in message
>>
>> >> > On 3 mai, 18:45, "David Cressey" <cresse..._at_verizon.net> wrote:
>> >> >> "Bob Badour" <bbad..._at_pei.sympatico.ca> wrote in message
>> >> > [Snipped]
>> >> >> Maybe I cut him too much slack. If the past is any guide,
>> >> >> optimizers
>> >> >> will
>> >> >> get better, and Brian won't. It's instructive that Both Cimode and
>> >> >> Kevin
>> >> >> provide actual data, while Brian merely states his claim.
>> >> > For my defense, I am trying to trigge questions here. It would be
>> >> > illusional ton my part to hope to get definite answers.
>>
>> >> >> But even if he wins this particular race, he will not convince me
>> >> >> that
>> >> >> cursors are the way to go. I've seen too much evidence to the
>> >> >> contrary.
>> >> > You will soon realize that Brian mainly tries to convince himself.
>> >> > Getting out of procedural mindset is nothing but *natural* instinct.
>>
>> >> Could you please elaborate? I don't need convincing. Sometimes I dip
>> >> into
>> >> waters that a bit too deep and end up chewing on my foot, but when I
>> >> know
>> >> I'm right, I don't need convincing, and I certainly don't try to
>> >> convince
>> >> myself.
>> > You are in denial. Don't you realize that at least 4 people have told
>> > you the exact opposite of your claims and you are refusing to admit
>> > they may just be right. Is 'nt there a slight doubt in your mind that
>> > you may be missing something ? that some aspect of fundamental theory
>> > may have elluded you?
>>
>> There is an understandable but unreasonable bias against cursors in this
>> group. I wouldn't be surprised if 15 people told me I was full of it,
>> since
>> most of the time, cursors are used incorrectly or where a set-based
>> solution
>> would perform better, and once someone has had a bad experience, it's
>> difficult to set aside emotionalism and examine a similar solution
>> dispassionately.
> Have you considered the idea that some people here were once in your > exact shoes and they once may had the unshakable belief in what you > just wrote. >
I only know what I have experienced, and to me it makes sense. Every optimizer step is implemented in the engine by using some form of iteration. What I'm suggesting effectively replaces several optimizer steps with a single user-defined one that makes a single pass through the data--similar to what a step that computes aggregates does. Now, I grant that a user-defined optimizer step will execute slower than a native one--in fact, I've actually timed it on Sql Server: a cursor making a single pass through a result set to populate a temporary object takes roughly twice as long as a comparable insert...select. The key is to eliminate any additional hits on the database within the fetch loop. This ensures that the step executes in linear time.
>> I guess I'm going to need some test data. So that we can compare apples
>> to
>> apples, could you tell me if the frequency of nulls in the test data of
>> your
>> original post is representative of that for the entire table, and if not,
>> could you let me know what that frequency is?
> Fair enough. Give me some time to apply Vadim's formula to the posted > set of data. (+ same structure) Then it would be interesting to set > an intensive IO concurrent stress. There is a free tool called DB IO > stress which has the advantage of generating stress asynchronously > and in which different select's (different from the interpolation > select) can be simulated. Doing the same test on a few dbms's may > prove interesting. > > >Received on Fri May 04 2007 - 14:27:54 CEST