Re: Batch Billing Performance.

> Reply to fkolmann@revlon.com.au:

The point that creating a lgl can be detrimental I cannot understand.
What this means to me is that the optimiser makes a mistake.



An unnecessary logical does not really hurt SQL that much, (course it gives it
one other option to always keep checking) The problem is the possible effect on
the entire system, not just SQL.  If logicals had no affect on performance the
obvious thing to do to get a high performance system is to build separate
logicals over every field and every possible access path in a file.

With a relatively stable file like the IIM this approach might not impact system
performance all that much, but everytime you modified a field that was a part of
an index for a logical, the logical also has to be updated. All that much is a
relative term,

For a file that sees a lot of activity this could be a killer. Every insert and
delete means the system has to go out and update every active (not deferred
update) logical built over that file. Although the updates of the logicals are
usually not as expensive as the updates of the base file, it is still similar to
adding an extra file io and update for each extra logical you build. It is not
really as bad as it sounds, however the point is the extra logicals don't come
for free.  However if well chosen they MORE than pay for themselves in improved
overall system performance. It's similar to the pay me now, or pay me later
commercial. Is it cheaper to pay now, or pay later? Answer: it depends.

Harmon Zieske
Nexgen Software Technology


+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---