> Yep, I mean this is always the case for corpus-level algos right?
I am not sure which parts of which calculations lucene (Elastic Search and Solr) does on the fly vs pre-calculates after any change to corpus, because it's more or less transparent. I mean, I guess that's not entirely true -- there are definitely index-rebuilds that happen after updates, and for larger-scale things they can be resource-intensive enough that you have to account for them (for very small-scale things you can more or less ignore them), maybe it's just that Solr/ES have architectures built around accounting for that and giving you tools to deal with it with various approaches.
Yep, I mean this is always the case for corpus-level algos right?
No reason you can’t do it iteratively —- postgres has triggers…
Oh but actually thinking about it, it could be a function! You’d just need access to that intermediate representation.
> I suspect most people would not be interested in such an approach, instead either making do without TF/IDF, or moving to a non-pg solution.
Well people would be happy if it was there at all, I think. Then they could at least make the choice or have a decent option.
It probably won’t be as performant as other solutions which can make more drastic architecture changes but… might still be worth having