Wild Card/Generic retrieval
Darren Reely
darren.reely@latticesemi.com
Wed, 10 Sep 2003 13:56:53 -0700
That cursor example is what I did not include, but mentioned. The time
was 2 minutes 47 seconds. I just reran the test and got 2 minutes 36
seconds. I did find this a surprising result. After all, you'd expect
the query to filter out rows that the other tests have to go through.
Understanding that Quiz is doing a little more work I tried to sway
Oracle to do the same via my subselect example. Somehow Oracle 'saw'
through that, or worked much more efficiently at its low levels. Quiz on
the other hand still fetches real data from Oracle before applying the
SELECT, taking up crucial time. Oh, and Quiz is placing that fetched
data somewhere else also.
Here is a new faster version of the cursor sample. It takes 10 seconds.
set report nolimit
sql in mfg declare lss cursor for select lot_id from lot_step_summ
where lot_id like '%A'
access lss
define mycount num = 1
final footing mycount subtotal
This suggests that when fetching data, you should only fetch what you
need, not everything, as the SELECT * does. Temporary Quiz storage
concerns are not being taxed as much in this new example.
My testing was a simple curiosity experiment. Real reporting could alter
the results somewhat. Still, I know to avoid MATCHPATTERN, and SELECT *
when not required.
Darren
Deskin, Bob wrote:
> Well, QUIZ is retrieving each individual row from the database and
> then applying the selection. The SQL is letting the database do all of
> the selection before returning anything.
>
> How about trying this:
>
> declare x cursor for select select * from lot_step_summ where lot_id
> like '%A'
> access x
> define mycount num = 1
> final footing mycount subtotal
> go
>
> or something similar.
>
> Bob
>
> -----Original Message-----
> From: Edis, Robert [mailto:REdis@Blistex.com]
> Sent: Wednesday, September 10, 2003 3:37 PM
> To: Powerh-L (E-mail)
> Subject: RE: Wild Card/Generic retrieval
>
> What IS an issue is 4 sec. for SQL vs. 53 sec for Quiz. Why is
> Quiz so slow?
>
> -----Original Message-----
> From: Deskin, Bob [mailto:Bob.Deskin@cognos.com]
> Sent: Wednesday, September 10, 2003 2:25 PM
> To: 'Darren Reely'
> Cc: powerh-l@lists.swau.edu
> Subject: RE: Wild Card/Generic retrieval
>
> Thanks Darren for confirming that pattern matching is still
> quite resource intensive relative to the other PowerHouse
> functions. While we can't say exactly how much more intensive
> without testing various volumes, I'm not surprised at these
> results. What is interesting is how close the other function
> tests are.
>
> Bob
>
> -----Original Message-----
> From: Darren Reely [mailto:darren.reely@latticesemi.com]
> Sent: Wednesday, September 10, 2003 2:57 PM
> Cc: powerh-l@lists.swau.edu
> Subject: Re: Wild Card/Generic retrieval
>
>
> I found this interesting enough to 'play' a little with it. I
> choose the
> main table in our Oracle test system containing 1,482,455
> rows. I
> altered the queries for my known data and limited them to
> counting.
>
> In this scenario it is obvious to avoid MATCHPATTERN. I've
> never been
> impressed with its performance. Most of the options proposed
> came in at
> around 53 seconds, MATHCPATTERN added 2 minutes to those times!
>
> Not listed here is a combination of the Oracle SQL select as a
> cursor
> for a new version of the quiz file. It took 2 minutes 47 seconds.
>
> At the end of each select statement are the timings.
>
> Oracle SQL - approximately 4 seconds
>
> select count(*)
> from lot_step_summ
> where lot_id like '%A';
>
> OR
>
> select count(*)
> from (select * from lot_step_summ where lot_id like '%A');
>
>
> COUNT(*)
> ----------
> 145878
>
>
> Powerhouse times
>
> set report nolimit
> access lot_step_summ in mfg
> ;select lot_step_summ if MATCHPATTERN(TRUNCATE(lot_id),"@A")
> ;; 2
> minutes 53 seconds
> ;select lot_step_summ If 0 = index(lot_id,"A") -
> size(truncate(lot_id))
> ;; 53 seconds fetches too many records, no surprise
> ;select lot_step_summ if 'A' = REVERSE(TRUNCATE( lot_id
> ))[1:1] ;; 53
> seconds
> select if "A" = lot_id[ SIZE(TRUNCATE(lot_id)) :
> 1] ;; 56 seconds
> define mycount num = 1
> final footing mycount subtotal
> go
>
> 09/10/2003
> mfg
> PAGE 1
>
> MYCOUNT
> (SUBTOTAL)
>
> 145878
>
>
> Darren
>
>
> = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> Mailing list: powerh-l@lists.swau.edu
> Subscribe: "subscribe" in message body to
> powerh-l-request@lists.swau.edu
> Unsubscribe: "unsubscribe <password>" in message body to
> powerh-l-request@lists.swau.edu
> http://lists.swau.edu/mailman/listinfo/powerh-l
> This list is closed, thus to post to the list you must be a
> subscriber.
>
> Join us at Cognos' biggest event of the year Enterprise 2003,
> The Cognos Business Forum. Taking place in over 25 cities
> around the world, it's an opportunity for Business and IT
> leaders to learn about strategies for driving performance.
> Visit http://www.cognos.com/enterprise03 for more details.
>
> This message may contain privileged and/or confidential
> information. If you have received this e-mail in error or are
> not the intended recipient, you may not use, copy, disseminate
> or distribute it; do not open any attachments, delete it
> immediately from your system and notify the sender promptly by
> e-mail that you have done so. Thank you.
>
>
> Join us at Cognos' biggest event of the year Enterprise 2003, The
> Cognos Business Forum. Taking place in over 25 cities around the
> world, it's an opportunity for Business and IT leaders to learn about
> strategies for driving performance. Visit
> http://www.cognos.com/enterprise03 for more details.
>
>
> This message may contain privileged and/or confidential information.
> If you have received this e-mail in error or are not the intended
> recipient, you may not use, copy, disseminate or distribute it; do not
> open any attachments, delete it immediately from your system and
> notify the sender promptly by e-mail that you have done so. Thank you.
>