# Deleting documents by date

**URL:** <https://discuss.elastic.co/t/deleting-documents-by-date/82276>\
**Category:** Elasticsearch\
**Created:** [April 13, 2017, 10:51am UTC](https://discuss.elastic.co/t/deleting-documents-by-date/82276 "2017-04-13T10:51:23Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![theuntergeek](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/theuntergeek/32/44961_2.png) [@theuntergeek](https://discuss.elastic.co/u/theuntergeek)\
**Post date:** [April 13, 2017, 11:11am UTC](https://discuss.elastic.co/t/deleting-documents-by-date/82276/2 "2017-04-13T11:11:53Z")

</div>

It's a lot like comparing a sql `DELETE from TABLE where date<YYYY.MM.dd` to a sql `DROP TABLE`. One has potentially millions or billions of rows of atomic operations, where the other is a single operation. Which is more performant?

In terms of _operational_ efficiency, you end up needing a lot of extra read/write operations to actually delete things in a Lucene index. First, you have to _find_ what to delete (read operation). Then you need to _mark_ the documents for deletion (write operation). Then, at the next segment merge, Lucene has to _find_ the documents marked for deletion (read operation), and make new segments without those documents (write operation).

But it's not merely _operational_ efficiency, but segment fragmentation that will be your enemy over time, robbing you of valuable _storage_ efficiency. See [http://blog.mikemccandless.com/2011/02/visualizing-lucenes-segment-merges.html](http://blog.mikemccandless.com/2011/02/visualizing-lucenes-segment-merges.html) for a brilliant view into what happens with segment deletes (which come with document deletes) and how it interrupts the normal, efficient, tiered segments of a lucene index.

This is why we don't recommend delete\_by\_query as a solution for time-series data.

---

_[View the full topic](https://discuss.elastic.co/t/deleting-documents-by-date/82276)._