Re: Performance Issue on Large Table
Richard Damon <[email protected]> Sun, 23 Feb 2020 14:23:27 -0500
| Newsgroups | gmane.comp.db.sqlite.general |
|---|---|
| Message-ID | <[email protected]> |
On 2/23/20 8:31 AM, Olaf Schmidt wrote: > Am 21.02.2020 um 02:24 schrieb Chip Beaulieu: >> I have a table with 4.5 million records with full text indexing. > >> Reads are very fast, but deleting / inserting / updating >> takes on average about 50 seconds per record. I often do batches of >> 30,000 deletes / inserts at a time. The last batch took 10 hours to >> complete. > > These 30,000 deletes+inserts indicates that these were the > verse-records of a complete Bible-Content, right? > > And your 4.5Mio records total indicate, that you have about > 140 different Bible-versions in your DB? > >> I suspect it’s got something to do with the triggers more than the >> indexes. > Could be - but my guess is, that your primary DB-changes are caused > by "deleting or inserting verses of whole bible-contents". > > So why not handle (hold) each bible in a separate table? > > An amount of 140 tables in such a "BibleVersions.db" is not > uncommon and can be managed by SQLite in a good performance. I'm not sure that form of division would be good. One basic rule of database normalization is that you don't break-up data based on the value of one of the fields because you can't make the table to lookup data from be taken from a field you get in a query. -- Richard Damon _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users