Path: news.f.de.plusline.net!news-fra1.dfn.de!newsfeed.hanau.net!newsfeed01.sul.t-online.de!t-online.de!solnet.ch!solnet.ch!newspeer1.nwr.nac.net!border2.nntp.dca.giganews.com!nntp.giganews.com!cyclone1.gnilink.net!spamkiller2.gnilink.net!gnilink.net!trndny06.POSTED!3abab865!not-for-mail From: "David Cressey" Newsgroups: comp.databases.theory References: <1178028682.007857.36200@p77g2000hsh.googlegroups.com> <1178130430.502230.295300@u30g2000hsc.googlegroups.com> <1178174344.866049.272810@h2g2000hsg.googlegroups.com> <6ui_h.5979$YW4.662@trndny06> <4639fde8$0$4017$9a566e8b@news.aliant.net> <1178211370.791765.118760@l77g2000hsb.googlegroups.com> <1178221012.371056.145700@u30g2000hsc.googlegroups.com> <1178260494.811737.293620@y5g2000hsa.googlegroups.com> <8kY_h.7025$2v1.1573@newssvr14.news.prodigy.net> <463c813c$0$4036$9a566e8b@news.aliant.net> Subject: Re: A new proof of the superiority of set oriented approaches: numerical/time serie linear interpolation Lines: 47 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Message-ID: <4u%_h.1523$rk5.569@trndny06> Date: Sat, 05 May 2007 13:17:52 GMT NNTP-Posting-Host: 72.70.235.201 X-Complaints-To: abuse@verizon.net X-Trace: trndny06 1178371072 72.70.235.201 (Sat, 05 May 2007 09:17:52 EDT) NNTP-Posting-Date: Sat, 05 May 2007 09:17:52 EDT Xref: news.f.de.plusline.net comp.databases.theory:43780 "Bob Badour" wrote in message news:463c813c$0$4036$9a566e8b@news.aliant.net... > David Cressey wrote: > > > "Brian Selzer" wrote in message > > news:8kY_h.7025$2v1.1573@newssvr14.news.prodigy.net... > What can one say? Selzer's rant speaks to a shitty optimizer. It > condemns a specific un-named product and nothing else. > I have done lots of optimization. I have never achieved a gain from > using a cursor, and I have achieved numerous huge big-O improvements by > getting rid of cursors. Like taking an O(n^5) cursor algorithm and > replacing it with a single select statement involving multiple joins, > quantification and correlated subqueries that executed in O(n) -- and > that was using a small footprint embedded dbms one could buy for a > couple hundred dollars. > > Within a few moments of inheriting the cursor based code mentioned > above, I recognized the cursor solution would not scale and I changed > it. My boss was suitably impressed when he asked me to look into a > performance problem found in the field, and I replied that I had already > found it and fixed it. Thanks Bob. The above comments put things back into perspective. Especially the point about big-O. I'll admit that my experience was not mainly about dealing with preformance issues as such, except for one or two contracts. In general, the rule about design and development was: Use simple and sound design principles, make sure the overall design won't crumble due to a single fatal flaw, and use default methods and parameters on the first go round. Tune when necessary. Over time, I developed a list of ten things to look for when a database was running slow (I realize that's sloppy terminology, but it's intentional). These ten things were generally peculiar to VMS and Rdb/VMS, although some of them might port. I think I'll start a new thread on "Self joins and optimization" so as to avoid hijacking the thread on interpolation.