Question about field indexer

[yaisog]

I tried to figure this out using the documentation and the change descriptions here on GitHub, but wasn't totally successful. It's about the 128 character limit for the field index and queries against it.
What exactly happens when e.g. the tags field of a single tiddler is longer than 128 characters? Do all tag filter queries fall back to the non-indexed method, since not all tiddlers' tags fields are indexed?
What I'm asking is, do I need to watch the length and number of tags I'm using if I want the performance improvement from indexing?
Best regards
Yaisog

[yaisog]

Being the impatient sort, I took a look at the code (should've done that to start with). Since I'm no JS wizard, please correct the conclusions I've drawn from it, if necessary:

• tags have their own indexer which works a bit differently, since the tags field is a list
• the tags indexer has no length limit, so my previous question it pointless
• the field indexer is mostly useful for value fields – if I wanted to use a field to build an alternate tag-like hierarchy, the indexer wouldn't help (corresponding filters would use the contains operator and not the indexed field operator)
• an alternate tagging scheme using a different field would be slower than using tags, even if that meant tag bloat

I was thinking of using an alternate field / list to tag Journal tiddlers which can refer to a number of "main" tiddlers, to reduce the number of tags in my wiki. I'm gonna drop that idea until TW implements a general list index that the contains[] filter uses.
Best regards
Yaisog

PS: In my wiki of 9 MB and with 4,500+ tiddlers and 1,000+ tags there was no measurable difference between using tag[] and contains:tags[], at least on my machine. I "measured" with a list widget in a tiddler that I folded and unfolded repeatedly, looking at the performance data in the console. So maybe the data is skewed because (un)folding changes state tiddlers and thus causes an index rebuild?

PS2: Running the risk of this becoming a soliloquy, when duplicating the above list widget 100× inside the tiddler, the difference between tag[] and contains:tags[] becomes indeed measurable and significant. So using tags instead of an extra field for tagging-like purposes can have a performance impact, depending on the number of list calls.

PS3: Okay, I hacked together an indexer for my custom field mostly by copy/rename/pasting the tag-indexer, and extended the contains filter to use the index if available by copy/pasting from the tag and field filters. It's a bespoke solution for my particular wiki and probably not very future-proof, but it works and it's fast. Since I only have about half the tags remaining in the wiki now, even the tag filter seemed to have become a bit faster.
I wish there was a filter like tags for arbitrary list fields. I'm making do with [get[references]enlist-input[]unique[]] for now (references is my custom field), but it feels a bit clumsy.

PS4: Well, since this feels a lot like blogging, I'm gonna go ahead and tell the world how the story continued. I undid it all. I had adapted a lot of places where I used to use tags to use the new references field instead. I cloned and adapted the tags-EditTemplate to be able to comfortably assign references instead of tags that were drawn from their own pool (to keep both lists somewhat shorter). I even had a distinct visual design to easily distinguish tags from references. But it was a rabbit hole. To really get this integrated would have been a lot more work, and all just to have a few less tags in the wiki.
Maybe I'll implement a way to dynamically subset active tags by showing only descendants of some selected root tag to reduce the clutter (e.g. in the tag-picker and/or search results). I wish I could use bimlas' kin filter for that, were it not so sluggish. If there only was a way to combine it with an index...

PS4½: I'm marking this as the answer to close the question, as it is no longer relevant.