Accelerator tables (also called pivot and variable tables, "saved search acceleration") are BPM / BAW's way to make searches over business data fast. The problem they solve: a Process Portal saved search that filters on exposed business data (customerName == 'Acme') has to look into every instance's variables; without acceleration BPM scans the serialised execution context of the matching instances - slow on large databases.
- Variable table (LSW_BPD_INSTANCE_VARIABLES) - one row per instance and exposed business variable with its current value (updated by the engine whenever the variable changes). A search can then filter in SQL.
- Pivot tables (LSW_BPD_INSTANCE_VARS_PIVOT and per-search pivots) - the variable table turned sideways: one column per searched variable, so that the search is a single indexed SELECT; they are (re)generated per saved search by the optimize operation and loaded with the current data.
Management: Process Admin > Instance search acceleration (optimize / drop pivot tables) on 8.5.7 and later; on BAW 20+ the Operations REST API exposes the same: POST /ops/std/bpm/saved_search_acceleration/optimize (generate the pivot tables and load the variable data) and the drop pivot tables operation.
# BAW 20+ Operations REST
POST /ops/std/bpm/saved_search_acceleration/optimize -> generates the pivot tables for the current saved searches and loads the variable data
GET /ops/std/bpm/saved_search_acceleration -> status
# rerun after new saved searches on business data were created, or after a large instance cleanup
Guidelines: expose as business data only variables you really search on (each one costs a write per change); run the optimisation after creating saved searches and after big cleanups; index the variable table on the columns your searches use if the DBA sees full scans; on CP4BA the same tables and REST resource exist. Question 3121 style SQL against these tables is fine for reporting on current values.
References