Re: SQL - EXISTS

This interactive program from menu to first display, was taking /an
average/ of five minutes when I started on it.

Be careful Alan! the users may be banking on those 5 minutes to grab a cup
of coffee.
I had stumbled on a job that was in "RUN" status for lots of minutes,
found the program, and
saw the program was looking for "active records" on the non-keyed
physical. I changed to logical, and
the program went from 8 minutes to start to sub-second. MAN, the user
was P.O. at me.

On Wed, Nov 23, 2022 at 1:55 PM Alan Cassidy <cfuture@xxxxxxxxxxx> wrote:

I agree, D*B.

This interactive program from menu to first display, was taking /an
average/ of five minutes when I started on it. The programmer that
worked on it before me even did a popup window when they did an F3-Exit
asking if they really wanted to exit, because every Exit cost them five
minutes to get back in. It's now /way way/ down from that, but still
horrendous performance.

I offloaded one algorithm to an external procedure that kept some
internal variables static where they didn't change much.

I converted a whole lot of RPG I/O code (SETLL, READE, CHAIN, CHAIN
CHAIN) to an SQL View that feeds all the twenty or so users jobs, where
the joins and CASE WHERE happens only there. It was reading every single
record in the primary file in every user's job and CHAINing a bunch of
others, some of which it had to read through groups in other files
looking for a value to match.

In the program I'm working on now, there's one condition that
reads-equal through a group of records to check for a match to a list
that is in a table from a generic file. I'm going to front-load those
values to an array with ASCEND to do a %lookup instead. That made a HUGE
difference in one place I worked at before.

--Alan


On 11/23/2022 9:01 AM, D*B wrote:

... if the query analyzer does its job, it choose the best way to get
the result. best way could depend on index design, balance of the
table, number of records, etc.

if you have "a /very /heavy performance burden", first step would be
to analyze and to understand why the database engine is needing so
much time (database monitor is your friend) before trying to optimize.
mostly modifying statements doesn't help too much. ceating a missing
index or changing your access logic or changes to database design
could bring better results!

D*B

<Alan>
SQL references gives an example of EXISTS:

EXISTS (SELECT *
FROM EMPLOYEE WHERE SALARY > 60000)

I would assume that the search in file EMPLOYEE stops when it finds the
first instance of a row that matches.

Is that so?

I'm asking because I'm modifying a program that has a /very/ /heavy/
performance burden, and I have to squeeze milliseconds out of it
anywhere I can get it.
</Alan>

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com