Bij grote bestanden mislukt opslaan door: The table '#__finder_tokens' is full

Het eerder gemelde probleem is nog steeds niet opgelost, maar ik heb op het internet gezocht naar problemen met 'finder tokens' bij grote bestanden als 'slim zoeken' is ingeschakeld en ik kwam een stukje tegen over indexeren, dat zag ik al onder het kopje 'slim zoeken' staan in Joomla, met de standaard instelling van 30000 (tokens).

Vrij vertaald staat er dit:
... het probleem met de indexer bij grote inhoudsitems ontdekt.
Het lijkt erop dat FinderIndexer :: addTokensToDB momenteel altijd 1 retourneert als het aantal tokens moet worden geretourneerd toegevoegd aan de database.
Het geretourneerde aantal wordt gebruikt om te meten of de schijf moet worden gebruikt i.p.v geheugen.
Daarom was het effectiever om fragmenten/stukken te tellen i.p.v het aantal tokens.
Omdat het aantal fragmenten/stukken nooit in de buurt komt van de standaard limit van 30000 (tokens), switcht de indexer nooit naar de schijf en faalt als de geheugentabel de standaard limiet bereikt van 16MB.

Als ik het goed begrepen heb zou de indexer bij grote bestanden moeten switchen naar de schijf i.p.v het geheugen blijven gebruiken.
Maar ik heb onvoldoende ervaring met databases om zonder 'ervaren hulp' zelf daaraan te gaan knutselen.

Het oorspronkelijk artikel staat ' hier '.

Geef nou eerst eens aan waarom je per se Slim Zoeken wilt gebruiken. Met de huidige opbouw van jouw site heeft dit totaal geen nut namelijk.

Als ik je eerder goed begrepen heb, schreef je dat indexeren in 'slim zoeken' alleen van invloed is op de inhoud van een site.
Daarbij horen volgens mij ook de verschillende pagina's in een site.
Misschien met uitzondering van pagina's gegenereerd door bijvoorbeeld een component dat de inhoud van een csv bestand in een menu item (joomla) weergeeft e.d.
Maar 1 van deze pagina's bevat de handleidingen, dat is ook meteen de pagina waar zich het probleem met 'table ... is full' voordoet omdat ik er teveel tekens/woorden in wilde opslaan, toch zal de inhoud van het artikel blijven groeien met nieuwe handleidingen.
Een deel van de inhoud bestaat uit de accordion met tabs, accordion_ID's en accordion_items.
Ik kan maar een beperkt aantal tekens in het artikel opslaan, totdat de eerder genoemde foutmelding verschijnt.
Door dat probleem op te lossen, kan je met 'slim zoeken' sneller resultaten vinden als je een handleiding zou zoeken a.d.h.v bepaalde steekwoorden zonder eerst de desbetreffende pagina handmatig af te hoeven struinen.

Maar ik sta open voor alternatieven waarmee ik het lang zoeken kan voorkomen.

En daar zit jouw denkfout: slim zoeken vindt je handleiding en zal het zoekwoord tijdens het zoeken highlighten. Maar meer gebeurt er niet. Dus je weet dat het zoekwoord in het artikel zit, maar je zult het nog zelf moeten gaan zoeken nadat je het artikel hebt geopend.

Met 'highlighten' bedoel je de opsomming (in de vorm van lijstweergave) waar een bepaald gezocht woord in is voor gekomen, toch?
Als dat het geval is, dan is dat precies wat ik zoek.
Want zonder 'slim zoeken' ben je toch veel langer bezig met zoeken, of vergis ik me daarin?

Je moet het zelf maar uitproberen. Als je de Geheugentabel limiet op 1 zet, dan zou je in principe geen foutmeldingen meer moeten krijgen (duurt wel wat langer dan). Dan zie je zelf wat het resultaat is als je slim zoeken gebruikt en kan je beoordelen of het aan je verwachtingen voldoet.