Hi Christine, Thanks for the response and the suggestion. This turned out to be quite a deep rabbit hole, but the following shows times for versions between 6.6 and 9.5.
Each row below gives the version followed by two times for the partial update of the 25 documents listed in my original post, each of which is an average of three runs with the first being the time for `stored="false"` and the second for `stored="true"` (both with `indexed="true" docValues="true"`; also, the initial add of 25 docs doesn't take more than 100-200ms or so in any version with either of these settings): Version, stored="false", stored="true 6.6.6, 1.934s, 2.253s 7.0.0: 1.913s, 2.034s 7.3.0: 1.897s, 1.690s 7.5.0: 1.710s, 1.807s 7.6.0: 3.066s, 2.719s 7.7.0: 3.537s, 3.444s 7.7.3: 3.128s, 3.403s 8.0.0: 3.460s, 3.499s 8.3.0: 3.462s, 3.656s 8.4.0: 6.790s, 6.910s 8.5.0: 6.832s, 6.722s 8.6.0: 7.217s, 7.068s 8.11.3: 7.612s, 7.619s 9.0.0: 7.170s, 7.005s 9.3.0: 7.255s, 7.336s 9.4.0: 8.960s, 8.627s 9.5.0: 8.510s, 0.012s It's not reflected in these partial update times, but I noticed that between 6.6.6 and 7.0 there was a big reduction in index size and decrease in time to build the index. 6.6.6 took almost 160 minutes to build the index from scratch and it was 41GB in size, while 7.0 took less than 15 minutes and was 15GB in size, so bravo to the team for such a drastic improvement. Looking at the first of the times (`stored="false"`) in each row above, it got much worse between 7.5.0 and 7.6.0 (1.7s to 3.0s), and then between 8.3 and 8.4 it gets worse again (almost doubling the time), and once more between 9.3 and 9.4, while the time for the `stored="true"` in each row seems to be roughly equal to `stored="false"` until it gets almost 1000x times faster with 9.5.0. Thanks, Calvin On Tue, Feb 20, 2024 at 1:52 AM Christine Poerschke (BLOOMBERG/ LONDON) < cpoersc...@bloomberg.net> wrote: > Hello Calvin, > > Thank you for this wonderful issue write-up! > > You mention upgrading from Solr 6 to 9.5 versions and I wonder if it might > be practical or insightful to assess for some versions in between too e.g. > 9.5/9.4/9.3 going backwards or 6/7/8/9.0 going forward or some sort of > binary search variant. > > Best wishes, > Christine >
