Bug 511873

Summary:	Processing the queue more efficiently and faster
Product:	[Applications] digikam	Reporter:	Andy <zunar>
Component:	Faces-Workflow	Assignee:	Digikam Developers <digikam-bugs-null>
Status:	REPORTED ---
Severity:	wishlist	CC:	metzpinguin
Priority:	NOR
Version First Reported In:	9.0.0
Target Milestone:	---
Platform:	Microsoft Windows
OS:	Microsoft Windows
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Andy 2025-11-09 16:41:30 UTC

Hi!
I have almost 209,000 entries in the faces database. When I select and confirm many faces, it always takes a very long time. (MariaDB remote on Synology NAS).
While the queue is processing, I see that the face overview and the "Number of New" faces found are constantly being updated.
Would the program run faster if the preview images were only updated after the queue has finished processing?

If background face scanning has been started automatically, it might help if it were paused when other tasks are added to the queue by the user.

Perhaps the queue would also process faster if only one task were executed at a time? This would only apply if the database is not located locally on the PC. 
You can certainly assess whether this is true much better than I can.

Regards
Andy

Comment 1 Maik Qualmann 2025-11-09 17:38:32 UTC

https://kb.synology.com/en-in/DSM/tutorial/mariadb_performance_tune
https://community.synology.com/enu/forum/1/post/187701

A MariaDB database on a NAS is rather slow.
There are many reasons for this.

Maik

Comment 2 Andy 2025-11-11 21:02:34 UTC

Hi!
I've now done a few things that Synology recommends:
- Btrfs is present. Unfortunately, I can no longer create an ext4 volume.
- I recreated the Docker share with the database without enhanced data integrity.
- innodb_flush_method = O_DIRECT
- An SSD cache is present.

You might also be interested in what the phpMyAdmin Advisor says about problems?

Here's an example after a short runtime:
Issue:
There are too many joins without indexes.
Recommendation:
This means that joins are doing full table scans. Adding indexes for the columns being used in the join conditions will greatly speed up table joins.
Justification:
Table joins average: 7.83 per minute, this value should be less than 1 per hour
Used variable / formula:
(Select_range_check + Select_scan + Select_full_join) / Uptime
Test:
value * 60 * 60 > 1


Andy

Comment 3 Andy 2025-11-15 18:31:07 UTC

Hi!

Or here's another tip from the Advisor

Issue:
The rate of reading the next table row is high.
Recommendation:
This indicates that many queries are doing full table scans. Add indexes where applicable.
Justification:
Rate of reading next table row: 32466.66 per second, this value should be less than 1 per hour
Used variable / formula:
Handler_read_rnd_next / Uptime
Test:
value * 60 * 60 > 1

If desired, I can post further tips.
Regards
Andy