|
You can use CHGQRYA to change QRYTIMLMT to 0 seconds. This stops the query itself from running (you get a message where you can ignore or cancel). The message will contain an estimate from the predictive query governer on how long the query will take to run. If you look in the job log you will see info messages on whether the query will need to build indexes or whatever in order to run the query. You can then change the query or build a LF and then try running it again to see if the estimated time is reduced. This allows you to experiment with speeding up queries without having to let the query run. By the way, you can set the QRYTIMLMT to some value to not let users run queries that the system estimates are going to run a very long time. There is also a system valueQQRYTIMLMT if you want to limit queries system wide. Scott Mildenberger > -----Original Message----- > From: Chuck Lewis [SMTP:clewis@iquest.net] > Sent: Monday, September 13, 1999 3:41 AM > To: MIDRANGE-L@midrange.com > Subject: Re: Query Performance > > Thanks Guys ! > > I'll try that. > > Neither of you played around with Predictive Query Governor or ever heard > of it ? > Know it's been around for awhile but also know that in general it's been > one of > those "well hidden secrets". > > Chuck > > > Pete Hall wrote: > > > At 08:20 09/10/1999 , Chuck Lewis wrote: > > >We've got "novice" query users creating queries over a 3rd party > > >applications' data base. They do a fairly good job in selection logic > > >but have no real knowledge of Logical Files so they are using Physical > > >Files which are NOT keyed so I am REALLY questioning the efficiency of > > >some of these queries. > > > > > >I know there is something called the "Predictive Query Governor" - is > > >any using this or have you and is it helpful in the above scenario for > > >"ratting out" problems ? > > > > The AS/400 will use the proper access path. You just need to make sure > that > > it exists. This often means running the most common queries in debug, > > examining the job log and creating whatever indexes are needed. > > > > Pete Hall > > pbhall@execpc.com > > http://www.execpc.com/~pbhall > > +--- > > | This is the Midrange System Mailing List! > > | To submit a new message, send your mail to MIDRANGE-L@midrange.com. > > | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. > > | To unsubscribe from this list send email to > MIDRANGE-L-UNSUB@midrange.com. > > | Questions should be directed to the list owner/operator: > david@midrange.com > > +--- > > +--- > | This is the Midrange System Mailing List! > | To submit a new message, send your mail to MIDRANGE-L@midrange.com. > | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. > | To unsubscribe from this list send email to > MIDRANGE-L-UNSUB@midrange.com. > | Questions should be directed to the list owner/operator: > david@midrange.com > +--- +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.