# Indexing to one shard is not concurrency-friendly?

**URL:** <https://discuss.elastic.co/t/indexing-to-one-shard-is-not-concurrency-friendly/59863>\
**Category:** Elasticsearch\
**Created:** [September 6, 2016, 9:47am UTC](https://discuss.elastic.co/t/indexing-to-one-shard-is-not-concurrency-friendly/59863 "2016-09-06T09:47:08Z")\
**Posts on this page:** 1\
**Showing post:** 5

<div class="post-metadata">

**Author:** ![Zline](https://avatars.discourse-cdn.com/v4/letter/z/e5b9ba/32.png) [@Zline](https://discuss.elastic.co/u/Zline)\
**Post date:** [September 12, 2016, 11:14am UTC](https://discuss.elastic.co/t/indexing-to-one-shard-is-not-concurrency-friendly/59863/5 "2016-09-12T11:14:52Z")

</div>

I can't use auto-generated IDs, but I suppose I could skip version check during initial indexing if I guarantee that where won't be concurrent updates. For more details please see [this thread](https://discuss.elastic.co/t/significant-overhead-of-concurrency-control-for-small-docs/60276).

Back on topic, I think concurrency problems are caused by contention inside [version control](https://discuss.elastic.co/t/significant-overhead-of-concurrency-control-for-small-docs/60276). At least partially.

---

_[View the full topic](https://discuss.elastic.co/t/indexing-to-one-shard-is-not-concurrency-friendly/59863)._