Logical base response very slow

• Article Type: General
• Product: Aleph
• Product Version: 20, 21, 22, 23

Description:
Logical base searches in bases representing different campuses/collections in our "ABC" consortium are uniformly slow.

util h/1/10 is also extremely slow.  The ret-03 Service could also be slow.

Resolution:
In order to avoid including all of the sublibraries for each campus in the base, the bases were defined in tab_base.eng with a truncated string. Example:

ABCMUP MUP Library ABCMUP ABC01 ABC01 N (wsl=mu?) not (wst=suppressed or wst=deleted or wst=circ-created)

The searching of severely truncated strings (such as "mu?") takes longer than other searches. Though there are relatively few sublibraries beginning with the letters "mu", there are thousands of *words* beginning with "mu". The Word search gathers *all* these records, then limits them to WSL.

util h/1/10 executes the tab_base.lng, col. 9, search parameters, as does p_manage_32 (via the b_build_cycle_table_base program and create_scope programs), when col. 8 = Y.

Changing the campus base definitions to include each sublibrary code explicitly, example:

ABCMUP MUP Library ABCMUP ABC01 ABC01 N (wsl=murow or muweb or mugov or musci or mumus or muarc or mucur or muims or mucsc or muint or murel or mufdc or muhar or mufit or muvrc or muill) not (wst=suppressed or wst=deleted or wst=circ-created)

greatly improved the response time for the base.

The moral: do not include severely truncated (2- or 3-character) strings as part of base definitions or as part of coded search strings, such as those on the Refine screen, or in the ret-03 Service.