Because of large common prefix hash naming becomes "too sequential" when
doing a lot of concurrent writes.
I don't know a good tradeoff between both use cases:
1. Lots of reads - prefers large shared prefix.
2. Lots of writes - prefers small shared prefix.
But as of now this punishes writes too badly in form of excessive
locking. Until a better fix is found, it's better to keep it prefix free.
---
A better fix would be a tradeoff of between these two:
1. Reads - temporal locality should result in spatial locality on disk.
2. Writes - temporal locality should NOT result in spatial locality.
temporal locality = data inserted around same time
spatial locality = data sits next to each other in DB pages.
This can be achieved by adding a small request/job specific part to
prefix so each concurrent request has it's own different locality when
writing data.
16407a50ec