RE: Indexing an SQL view

[Vern Hamberg <vhamberg@xxxxxxxxxxxxxxxxxxxxxxxxx>]

Exactly right - fewer I/O requests to get the data. That was a concern in 
the back of my mind as I gave the LF with substrings idea. But since there 
is no way now to have a usable SQL index over the original table to 
accomplish the stated purpose, the LF still seemd like a good idea. The PF 
with triggers might give better performance, but then you have disk space 
and other issues. Performance will vary according to how much 
update/delete/write activity there is.

Another idea is to have an empty PF with the desired substringed fields, 
and put an SQL index over it. Then do a CPYF FMTOPT(*NOCHK) into it when 
necessary. This is probably faster than an SQL INSERT, since there are no 
substringing calculations involved.

TMTOWTDI (Perl's "There's more than one way to do it")

Fortunately, Rick reports improvement.   ;-)

Vern

At 12:59 PM 4/19/2004 -0700, you wrote:
> Just a comment.  IBM has told me that an SQL Index retrieves data using a
> 16MB access but logical files use a 4MB access.  I'm not sure about the term
> "ACCESS" but I created a number of suggested views (from the V5R2 SQL
> Optimizer) and was able to see a better then 10 fold increase in performance
> (as measured in reduced response time).
> Bill Erhardt
>
> -----Original Message-----
> From: Rick.Chevalier@xxxxxxxxxxxxxxx [mailto:Rick.Chevalier@xxxxxxxxxxxxxxx]
>
> Sent: Monday, April 19, 2004 3:38 PM
> To: midrange-l@xxxxxxxxxxxx
> Subject: RE: Indexing an SQL view
>
>
> The creation of a DDS logical over the physical file with the substring
> values as keys seems to have done the trick.
>
> A lot of panic ensues here whenever triggers are mentioned so I don't think
> Walden's suggestion would get far.  Maybe we'll get indexed views soon.
>
> Thanks for all the help,
>
> Rick