High Load on (PostgeSQL)DB after upgrade to 4.2.1

Hi together,

since we upgraded to 4.2.1 we see a very high load on our db server. The load is caused by the following statement:

SELECT $1 AS "DN_TYPE","A0"."AUTHOR","A0"."BLAKE2B_256","A0"."BLAKE2B_384","A0"."BLAKE2B_512","A0"."BLAKE3","A0"."CLASSIFIER","A0"."COPYRIGHT","A0"."CPE","A0"."DESCRIPTION","A0"."DIRECT_DEPENDENCIES","A0"."EXTENSION","A0"."FILENAME","A0"."GROUP","A0"."ID" AS "NUCORDER0","A0"."INTERNAL","A0"."LAST_RISKSCORE","A0"."LICENSE","A0"."MD5","A0"."NAME","A0"."TEXT","B0"."ACTIVE","B0"."AUTHOR","B0"."CLASSIFIER","B0"."CPE","B0"."DESCRIPTION","B0"."DIRECT_DEPENDENCIES","B0"."GROUP","B0"."ID","B0"."LAST_BOM_IMPORTED","B0"."LAST_BOM_IMPORTED_FORMAT","B0"."LAST_RISKSCORE","B0"."NAME","B0"."PUBLISHER","B0"."PURL","B0"."SWIDTAGID","B0"."UUID","B0"."VERSION","A0"."PUBLISHER","A0"."PURL","A0"."PURLCOORDINATES","C0"."FSFLIBRE","C0"."ID","C0"."LICENSEID","C0"."NAME","C0"."ISOSIAPPROVED","C0"."UUID","A0"."SHA1","A0"."SHA_256","A0"."SHA_384","A0"."SHA3_256","A0"."SHA3_384","A0"."SHA3_512","A0"."SHA_512","A0"."SWIDTAGID","A0"."UUID","A0"."VERSION" FROM "COMPONENT" "A0" INNER JOIN "PROJECT" "B0" ON "A0"."PROJECT_ID" = "B0"."ID" LEFT OUTER JOIN "LICENSE" "C0" ON "A0"."LICENSE_ID" = "C0"."ID" ORDER BY "NUCORDER0" OFFSET $2 ROWS FETCH NEXT $3 ROWS ONLY

This statements is fired ~14.000 times per hour.

The execution plan looks alright though but i am not sure what values are used for the parameters:

--------------------------------------------------------------------------------------------------------------------- Limit (cost=87.06..173.14 rows=100 width=9591) -> Nested Loop Left Join (cost=0.98..279289.71 rows=324443 width=9591) -> Nested Loop (cost=0.70..184548.91 rows=324443 width=9507) -> Index Scan using "COMPONENT_PK" on "COMPONENT" "A0" (cost=0.42..84801.68 rows=324443 width=6040) -> Index Scan using "PROJECT_PK" on "PROJECT" "B0" (cost=0.28..0.31 rows=1 width=3475) Index Cond: ("ID" = "A0"."PROJECT_ID") -> Index Scan using "LICENSE_PK" on "LICENSE" "C0" (cost=0.27..0.29 rows=1 width=88) Index Cond: ("ID" = "A0"."LICENSE_ID") (8 rows)

Do you have any idea? I was not sure if this qualifies as issue or question, if this is not an issue please close.

Regards, Dennis

[davidkarlsen]

@nibiwodong take a chill-pill 😃

[lusor]

We found the cause of the issue: Deptrack has no stop condition (or probably a wrong one) for fetching the rows in batches. It tries to fetch rows starting from 25010000 while the table COMPONENT only has around 300k rows. The query then returns 0 results and Deptrack tries to fetch the next batch.