The following resources are used:

...

2 items for all items (except mod-data-import)

2 partition for all DI kafka topics:

Examples:

delete old topic
# ./kafka-topics.sh --bootstrap-server=<kafka-ip>:9092 --delete --topic perf-eks-folijet.Default.fs09000000.DI_ERROR

recreate topic with "--partitions 2 --replication-factor 1"
# ./kafka-topics.sh --bootstrap-server=<kafka-ip>:9092 --create --topic perf-eks-folijet.Default.fs09000000.DI_ERROR --partitions 2 --replication-factor 1
WARNING: Due to limitations in metric names, topics with a period ('.') or underscore ('_') could collide. To avoid issues it is best to use either, but not both.
Created topic perf-eks-folijet.Default.fs09000000.DI_ERROR.

get topic info
# ./kafka-topics.sh --bootstrap-server=<kafka-ip>:9092 --describe --topic perf-eks-folijet.Default.fs09000000.DI_ERROR
Topic: perf-eks-folijet.Default.fs09000000.DI_ERROR PartitionCount: 2   ReplicationFactor: 1    Configs: min.insync.replicas=1,message.format.version=2.6-IV0,unclean.leader.election.enable=true
    Topic: perf-eks-folijet.Default.fs09000000.DI_ERROR Partition: 0    Leader: 1   Replicas: 1 Isr: 1
    Topic: perf-eks-folijet.Default.fs09000000.DI_ERROR Partition: 1    Leader: 2   Replicas: 2 Isr: 2 (edited) 

mod-data-import: -XX:MaxRAMPercentage=85.0 -XX:+UseG1GC / cpu: 128m/192m | memory: 1Gi/1Gi

...

In the scope of FOLIO-3388 "item_status_name_idx_gin" index for the Item status field was removed from mod-inventory-storage. However, this index potentially can be used for matching by Item status during Item update.

jobprofile structure

Test results:

...

Job profile structure to update item and matching item by status field:

• Job profile
• Match profile (902$a to Item HRID)
  • For matches: sub match profile (Static match of "Available" to Item Loan and Availability Status)
    • For matches: action profile (action = update; Folio record type = Item)
      • Mapping profile (Folio record type = Item)

Test results:

...

This CQL query is translated by mod-inventory-storage to the following SQL:

SELECT id, jsonb, creation_date, created_by, holdingsrecordid, permanentloantypeid, temporaryloantypeid, materialtypeid, permanentlocationid, temporarylocationid, effectivelocationid
FROM fs09000000_mod_inventory_storage.item
WHERE (
	CASE WHEN length(lower(f_unaccent('Missing'))) <= 600 
		 THEN left(lower(f_unaccent(item.jsonb->'status'->>'name')),600) LIKE lower(f_unaccent('MissingAvailable')) 
		 ELSE left(lower(f_unaccent(item.jsonb->'status'->>'name')),600) LIKE left(lower(f_unaccent('Missing')),600) AND lower(f_unaccent(item.jsonb->'status'->>'name')) LIKE lower(f_unaccent('MissingAvailable')) 
	END
)
LIMIT 2 OFFSET 0

For the particular case when matching by item status is used as sub match profile, nobody index of the Item status field is used. Instead, a more efficient algorithm is applied to perform data lookup using the index for the id field.

"Limit  (cost=0.56..8.84 rows=1 width=1156) (actual time=0.038..0.040 rows=1 loops=1)"
"  ->  Index Scan using item_pkey on item  (cost=0.56..8.84 rows=1 width=1156) (actual time=0.038..0.039 rows=1 loops=1)"
"        Index Cond: (id = '4ae2603d-1f71-457f-b69a-3eed820d6cfb'::uuid)"
"        Filter: ("left"(lower(f_unaccent(((jsonb -> 'status'::text) ->> 'name'::text))), 600) ~~ 'available'::text)"
"Planning Time: 0.195 ms"
"Execution Time: 0.053 ms"

During the testing item update scenario it was observed that the "item_status_name_idx_gin" index deletion does not impact the performance of matching Item by status. According to the results of analysis, this index is not used for matching Item by status field during data import.