so the block cache should have somewhat larger effect on ingestion than before? If I’m understanding correctly

> The biggest tradeoff of using these bloom filters is that they can put more pressure on the RocksDB block cache.

further, I don’t need to wipe out local indexes for this change, unless I want to test full reindex improvements?

some (very) rough numbers, on my own machine I just tried a full reindex and it had indexed ~1.13x what the previous version had in the same 35minute time frame

but attribute-stats are different after full reindexing, (:xt/id (xt/attribute-stats node)) reports lower number

> so the block cache should have somewhat larger effect on ingestion than before? If I’m understanding correctly I didn't see any effect from changing the cache size before when measuring startup, but now it speeds up things until 64MB, so yeah, seems like the cache is now more important. But of course "more important" might still not be the bottleneck in any other situatioń

> attribute-stats are different after full reindexing, (:xt/id (xt/attribute-stats node)) reports lower number that doesn't sound right...roughly how much lower? is that with >500ms between checking for the latest stats to get written?

out of 1,4 million documents, I was missing roughly 30k

it was quite a while after finishing and latest completed vs submitted was the same

but I can’t remember if I had done the previous indexing with 1.22.0 (which also had stats problems)

I’ll run with 1.22.1 from start again and report back later

sadly, I’m missing ~50k of :xt/id in attribute stats

so 1.22.2-rc1 after full reindex reports much lower value than a full reindex with 1.22.1

Thanks @U11SJ6Q0K: https://github.com/xtdb/xtdb/issues/1852