Re: Deleted records and index size

On 03-Feb-2014 10:57 -0800, Alan Campin wrote:

<<SNIP>> If you delete a record, does the index size decrease?

No.

I am getting indications both way, that it keeps the deleted record
in index and logical indexes and other stuff that seems to say it
deletes the record from the indexes.

Any links to share what apparently so muddles the issue? However depending on the wording, both may be true. A delete record is not tracked to the index, but the actual tracking of the since-deleted row also is not purged entirely from the index.

Create a simple scenario, dump the index in STRSST D/A/D, delete a record, then dump the index again; review the difference.

I found IBM's information on calculating index size but it only says
number of records and nothing about deleted record.
It would seem logical that it would not keep an entry in the index.

When a dataspace index is built, deleted records are ignored; i.e. no data, no index entry.

Effectively, a DataSpace Index [*QDDSI] object can only grow. A deleted record is no longer tracked to the index. The node that formerly tracked the RRN is defunct; at least until that key value is re-inserted.

That is effectively the same situation for all index object types, because the underlying LIC IX index object, upon which other "index" object types are built, provides no method to decrease the size. An index object [with a visible manifestation to a user] will appear to decrease in size when the interface to that index enables a means to effect something like a rebuild, truncate, or reorganize feature for its underlying IX implementation object.

For a Library (*LIB) object [implementation object is a LIC IX object], that rebuild is available only with Create Library (CRTLIB). Having created a new IX index for the LIC Context [aka Library] object, into which objects can be created, restored, and moved, the index is filled [via INSOBJ] with each new object name\type\subtype combination as a new entry in that index.

For the database dataspace index [implementing the keyed Access Path], changing the index maintenance to *REBLD and then back to *IMMED should re-create a new underlying index [though the *QDDSI is the same object], thus decreasing the size. Similarly the old-style Reorganize Physical File Member (RGZPFM) [with ALWCANCEL(*NO)] will rebuild the non-unique index\access-paths. I expect also, the Force rebuild of access path (FRCRBDAP) on Change Logical File (CHGLF). For sure, creating a new index [that does not share] will create the index with what is effectively its minimal size [although like a dataspace, likely there is room-for-growth implicitly created, to avoid the need for adding more space when the first or first few entries are added].