Thank you for the response @thorben . Appreciate it.
Ok. Actually, the question came up with understanding of a point in above document where it mentioned “Process definition” also. So thought it might be caching around "ACT_RE_PROCDEF " table data also.
Follow up question on it:
Is not there any code to flush all the cache related (including process definition) data, when there is change in deployment data ? If there is modification/deletion around that deployment data, it must be deleting all cache related operation ? or may be this particular query should be touched for cache ?
Or
Can there be any way via custom cache implementation which can also cache it and flush it when there is any modification/deletion ?
Little more background :
Had enabled db operations related debug level to find how many db calls are involved in process execution (our setup where Camunda 7.20 is pointing to AWS Aurora Postgres instance), if inbuilt cache utilizing all possible cached data ? In performance insights, it shows most of wait time is in LWLock:BufferContent when tried a load test…
And most queries involved in wait are 3 :
insert into ACT_RU_EXECUTION ( ID_, ROOT_PROC_INST_ID ......
select distinct RES.* from ACT_RU_EXECUTION RES inner join ACT_RE_PROCDEF P on RES.PROC_DEF_ID_ = P.ID_ ........
select * from ACT_RE_PROCDEF where ID_ = $1
So thought if “select * from ACT_RE_PROCDEF” can be avoided which can ultimately help avoiding WAIT time on db operation to improve overall performance ?