# Merging two indexes by a common field

**URL:** <https://discuss.elastic.co/t/merging-two-indexes-by-a-common-field/96576>\
**Category:** Elasticsearch\
**Created:** [August 10, 2017, 9:12am UTC](https://discuss.elastic.co/t/merging-two-indexes-by-a-common-field/96576 "2017-08-10T09:12:49Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![Mark\_Harwood](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mark_harwood/32/10538_2.png) [@Mark\_Harwood](https://discuss.elastic.co/u/Mark_Harwood)\
**Post date:** [August 10, 2017, 10:08am UTC](https://discuss.elastic.co/t/merging-two-indexes-by-a-common-field/96576/6 "2017-08-10T10:08:59Z")

</div>

> [@marwa](#):
>
> yes i will do it regularly

Assuming you want to store costs/profit the best suggestion would be to fix your data "on the way in" if possible. 1,000 products is not a lot of data to keep in a RAM cache and lookup as you insert transaction data.  
Logstash I believe has some "lookup" type features that could help with this (best to ask in that forum).

Advantages to doing it this way rather than a batch fix-later scheme is

1. costs would be recorded with the values current at point-of-sale
2. there is no lag between the logging of transactions and costing of transactions.

---

_[View the full topic](https://discuss.elastic.co/t/merging-two-indexes-by-a-common-field/96576)._