RE: V5Rx Nuances

[Vern Hamberg <vhamberg@xxxxxxxxxxxxxxxxxxxxxxxxx>]

Mark, there's no necessary relationship between any of these things. I just
created an EVI, and the ACCPTHSIZ attribute is not even in the description.
EVIs, however, _can_ help make selection (WHERE clauses) work faster, if
used for the bitmap access method. Their maintenance has been rather
expensive in the past - I don't remember if this has improved in V5R2.

The help for ACCPTHSIZ says that high contention on an index can be helped
with the 1TB access path size. Associated with this, I believe, is the
locking behavior - the lock is at the record level, rather than at the
memory page level. something about, if you lock a record in an index, all
the other records in the including page are also locked in the 4GB type.

Someone help me here, I could be way off.

I did just see that access paths of a 1TB size cannot share those of a 4GB
size. That could have adverse affects on performance.

I also just saw a reference to a FRCRBDAP parameter that defaults to *NO -
there could be a lot of _delayed_ rebuilding going on, even when you change
to the larger size.

Search on "accpthsiz site:ibm.com" on google.

Regards

Vern

At 12:58 AM 12/8/02 -0500, you wrote:
> Joe,
>
> At 12/8/02 12:44 AM, you wrote:
> > I'm a bit confused here.  What's the relationship between *MAX1TB and EVI?
> > I thought EVI (Encoded Vector Index) was a special kind of index and you had
> > to do some magic to enable it.
>  I might be confusing the two, but I thought that enabling *MAX1TB enabled
> EVIs?  Or do EVIs require SQL?
>
>  -mark