# Historian Queries take very long, easy chart times out **URL:** \ **Category:** Ignition\ **Tags:** ignition79\ **Created:** [March 31, 2022, 3:54pm UTC](https://forum.inductiveautomation.com/t/historian-queries-take-very-long-easy-chart-times-out/57884 "2022-03-31T15:54:42Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![quartzFarm](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/quartzfarm/32/42037_2.png) [@quartzFarm](https://forum.inductiveautomation.com/u/quartzFarm)\ **Post date:** [March 31, 2022, 3:54pm UTC](https://forum.inductiveautomation.com/t/historian-queries-take-very-long-easy-chart-times-out/57884/1 "2022-03-31T15:54:43Z")
As our gateway has been growing our historian is getting incredibly slow. If I try to query more than 4 hours of data for a single analog tag the easy chart component will time out. I’m only historizing 465 tags, the majority are set for a 1 second scan class. All the others are set for 10 seconds. We started using Ignition in 2019. The sqlth\_te table has 27,926,615 rows. Does that seem excessive? Randomly in the logger I see queries show up, and the SELECT statements are massive, which I think is the cause of my issue. But don’t understand why it is happening. How long should a record in the sqlth\_te last for before it is retired? ---
**Author:** ![Matthew.gaitan](https://avatars.discourse-cdn.com/v4/letter/m/59ef9b/32.png) [@Matthew.gaitan](https://forum.inductiveautomation.com/u/Matthew.gaitan)\ **Post date:** [March 31, 2022, 4:06pm UTC](https://forum.inductiveautomation.com/t/historian-queries-take-very-long-easy-chart-times-out/57884/2 "2022-03-31T16:06:04Z")
The sqlth\_te table should only be getting updated if you make a change to a tag (Not sure if all tag changes insert a new record, or only those that are changing the scan class, data type, or query mode), so that row count seems extremely excessive How many sqlt\_data\_\* tables do you have? Do you have ignition setup to do automatic partitioning? ---
**Author:** ![kvane](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kvane/32/22228_2.png) [@kvane](https://forum.inductiveautomation.com/u/kvane)\ **Post date:** [March 31, 2022, 4:12pm UTC](https://forum.inductiveautomation.com/t/historian-queries-take-very-long-easy-chart-times-out/57884/3 "2022-03-31T16:12:18Z")
> I’m only historizing 465 tags > The sqlth\_te table has 27,926,615 rows You should probably contact [Support](https://inductiveautomation.com/support/home/) about this. The te table should typically not be growing that large. Support can assist in identifying the likely cause. Are you changing tag history settings on the tags automatically anywhere? ---
**Author:** ![quartzFarm](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/quartzfarm/32/42037_2.png) [@quartzFarm](https://forum.inductiveautomation.com/u/quartzFarm)\ **Post date:** [March 31, 2022, 4:18pm UTC](https://forum.inductiveautomation.com/t/historian-queries-take-very-long-easy-chart-times-out/57884/4 "2022-03-31T16:18:16Z")
I have a support ticket open. I’ll update it with a reference to this post. I just turned on data pruning to drop off everything older than a year. I was hoping to see the sqlth\_te table get cleaned up, but that doesn’t appear to be what happens. The partitioning settings are the default settings, which is 1 month. So currently I have just 13 sqlt\_data\_\* tables. ---
**Author:** ![kvane](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kvane/32/22228_2.png) [@kvane](https://forum.inductiveautomation.com/u/kvane)\ **Post date:** [March 31, 2022, 4:37pm UTC](https://forum.inductiveautomation.com/t/historian-queries-take-very-long-easy-chart-times-out/57884/5 "2022-03-31T16:37:30Z")
The sqlth\_te table doesn’t get pruned. Simply put, the table is storing static information needed to determine what history data is from what tag. When tags storing history are altered, it can result in new entries in the sqlth\_te tables. ---
**Author:** ![Matthew.gaitan](https://avatars.discourse-cdn.com/v4/letter/m/59ef9b/32.png) [@Matthew.gaitan](https://forum.inductiveautomation.com/u/Matthew.gaitan)\ **Post date:** [March 31, 2022, 4:43pm UTC](https://forum.inductiveautomation.com/t/historian-queries-take-very-long-easy-chart-times-out/57884/6 "2022-03-31T16:43:59Z")
While YMMV with support, we had issues with those database tables previously (unrelated to the issue outlined in this post), and support told us that they could provide us info on those tables, but it was up to us to fix it. We ended up having to rename the sqlth\_te table, let Ignition recreate it, then go in and update ALL of the sqlt\_data\_\* tables to point to the newly created tag id (and set the sqlth\_te “created” timestamp to the earliest instance of tag data for every tag) It was a royal pain