View Single Post
Old 07-31-2023, 10:59 PM   #12
BetterRed
null operator (he/him)
BetterRed ought to be getting tired of karma fortunes by now.BetterRed ought to be getting tired of karma fortunes by now.BetterRed ought to be getting tired of karma fortunes by now.BetterRed ought to be getting tired of karma fortunes by now.BetterRed ought to be getting tired of karma fortunes by now.BetterRed ought to be getting tired of karma fortunes by now.BetterRed ought to be getting tired of karma fortunes by now.BetterRed ought to be getting tired of karma fortunes by now.BetterRed ought to be getting tired of karma fortunes by now.BetterRed ought to be getting tired of karma fortunes by now.BetterRed ought to be getting tired of karma fortunes by now.
 
Posts: 21,832
Karma: 30277270
Join Date: Mar 2012
Location: Sydney Australia
Device: none
@droopy - I only keep a calibre FTS database on my Test library, so my comments mainly relate to using symlinks to calibre library metadata databases.

Quote:
Originally Posted by droopy View Post
I'm on Linux. Do you think I'll face a similar fate as you if I try the symlink suggestion?
Possibly, calibre loads the database into RAM at startup - that's why metadata searches, sorts etc are fast. On Windows/NTFS using a symlink to a database file on a Toshiba M1 NVMe SSD didn't improve performance over the SATA II WD Black HDD where my libraries are stored. If you have a faster SSD and slower HDD I suppose it might make a difference - suck it and see.

Quote:
Originally Posted by droopy View Post
Can I ask why you haven't tried you CALIBRE_OVERRIDE_DATABASE_PATH variable suggestion?
I have multiple libraries (because I have disparate custom columns), however the env-var approach assumes a single library. Besides I see no reason why it would perform any better or worse than a symlink that references an SSD resident database.

BR

Last edited by BetterRed; 07-31-2023 at 11:21 PM.
BetterRed is online now   Reply With Quote