# Non-Clustered index on timestamp in data-partition tables - is this necessary?

**URL:** <https://forum.inductiveautomation.com/t/non-clustered-index-on-timestamp-in-data-partition-tables-is-this-necessary/66238>\
**Category:** Ignition\
**Tags:** ignition81, database\
**Created:** [November 8, 2022, 5:00pm UTC](https://forum.inductiveautomation.com/t/non-clustered-index-on-timestamp-in-data-partition-tables-is-this-necessary/66238 "2022-11-08T17:00:49Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![tmahaf](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/tmahaf/32/23492_2.png) [@tmahaf](https://forum.inductiveautomation.com/u/tmahaf)\
**Post date:** [November 8, 2022, 5:00pm UTC](https://forum.inductiveautomation.com/t/non-clustered-index-on-timestamp-in-data-partition-tables-is-this-necessary/66238/1 "2022-11-08T17:00:49Z")

</div>

Hello there.

It looks like the db engine when a new data-partition table is created creates the primary key clustered index on time and tagid, and also created a non-clustered index on timestamp.

These non-clustered indexes take up quite a bit of room since there are so many unique timestamps for each data partition. I have done a little experimentation with removing the timestmap index on a table and running a handful of queries, and the query times don't seem to change much, if at all. I'm not a database guru but, since I do understand that since the data is already sorted by tagid and timestamp, the non-clusted index seems a little redundant, and also leads to the database getting larger a lot faster (for my table it halved the table size after I removed it).

Anyways, just curious to see if anyone else has gone down this road and experimented with these indexes as well, in hopes of getting their DB bill down a bit while not sacrificing performance.

Thanks!