× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: SQL select via logicals
  • From: David Morris <dmorris@xxxxxxxxxxxxx>
  • Date: Tue, 02 Dec 1997 09:54:56 -0700

>>> Vernon Hamberg <hambergv@goldengate.net> 12/01 9:00 PM >>>
>David

At 02:26 PM 12/1/1997 -0700, you wrote:
>>>> John Carr <74711.77@compuserve.com> 11/30 10:18 PM >>>
>
>>>RE: Re: SQL select via logicals
>
>>>I also think it would be good to have a mechanism to force the inspection
>>>of all indexes before deciding to Sort, or Copy the data or Build an Index
>>>on the fly. 

>>>But I can't imagine how they would implement it.  I can see a new parameter
>>>on OPNQRYF but can't see how they would implement it in SQL. Unless it was
>>>a system wide System Value.

>>>John Carr

>>A system value and option on CHGQRYA would be better than nothing.

>>We have had some problems with the optimizer.  In a few cases it used 
>>a logical  for months and then, for no obvious reason, it times out and 
>>consistently builds an access path.  When you don't know what the access 
>>plan was it is difficult to determine why it is no longer being used.  In 
>these 
>>cases forcing the optimizer to look at possibilities would help.

>The changes you describe may have to do with changes in the file size.
>That's one of the factors used by the optimizer, which estimates the cost
>of performing the given query. Now, if you're talking embedded, the access
>plan is stored in the *PGM and would not change without some severe change.
>If you're talking OPNQRYF or interactive SQL or QMQRY or dynamic embedded
>SQL or SQL CLI, then the access plan is redetermined every it's run.

Dynamic SQL.

>Check out the Database Programming manual, the Data Management Guide, and
>the SQL Programming and Reference manuals. There are appendices that deal
>with query performance, as well as using STRDBG to see what the optimizer
>did. Changing the order of the files, whether in OPNQRYF or in an SQL
>statement, can have profound affects on the time it takes to execute a query.

Spent many hours doing that.

>Anyway, in the kindest possible way, RTFM. There's a lot of really
>excellent material that will help you in setting up these things.

>BTW, one thing you should almost always do (some OVRDBF issues aside, I
>think) is set the ALWCPYDTA(*OPTIMIZE) parameter of OPNQRYF.

ALWCPYDTA and OPTIMIZE have no effect when using For n Rows.  We use 
For n Rows based on file information because we cannot recompile each time 
a report is run.

>Cheers

>Vernon Hamberg

Vern,

Thanks for the suggestions. I have had to spend quite a bit of time trying to 
determine what slight change in the data caused the optimizer to determine 
that building an access path was best.  Rather than spending hours to save 
a few cycles I would rather be able to tell the optimizer I want you to use an 
existing access path because it worked well before and a I know it is better 
than building a new access path.

We do a lot of very dynamic reporting using SQL and it is not possible to 
predict 
how a file might be queried by a user this week.  We keep information about our 
files 
and use this when building select statements to apply the best access method 
(join
order, n rows, etc.).  We generate our SQL statements from files that tell us 
how our 
files are related etc.  We save the statements and have seen the exact same 
statement 
go from 1 minute to 2 hours.  If experience from the prior 300 runs tells us 
that with the 
selected files it has proven better to use an existing access path, we would 
like to at 
least be able to tell the optimizer not to give up easily.

One thing that used to be (still?) very annoying was when an file was open for 
update 
the associated access path was not considered.  Not mentioned in the manual and 
not 
considered a bug.  It took a lot of time to find this and got us a bill for 
several thousand 
dollars from IBM.  We switched to updating through the unkeyed physical to 
avoid this.

David Morris

                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
                                                                                
               
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@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 thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.