# Store & Forward Memory Buffer and Local Cache Overflow

**URL:** <https://forum.inductiveautomation.com/t/store-forward-memory-buffer-and-local-cache-overflow/42355>\
**Category:** Ignition\
**Created:** [January 18, 2021, 1:24pm UTC](https://forum.inductiveautomation.com/t/store-forward-memory-buffer-and-local-cache-overflow/42355 "2021-01-18T13:24:09Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![lrose](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lrose/32/62724_2.png) [@lrose](https://forum.inductiveautomation.com/u/lrose)\
**Post date:** [January 18, 2021, 6:30pm UTC](https://forum.inductiveautomation.com/t/store-forward-memory-buffer-and-local-cache-overflow/42355/4 "2021-01-18T18:30:56Z")

</div>

> [@DANewton](#):
>
> Could it be that querying and updating this table takes too long.

Almost certainly. Especially if you're seeing the issue escalate as we move further into the month.

> [@DANewton](#):
>
> When making a tag historical, the only option is what database is used. My understanding is that it’s the default sqlt\_data\_xxx table. Is there a way to designate the table data will be stored in?

On the gateway, for each historical provider you can configure the data partitioning. Just a caution that being to finite here can be as much of a headache as being to broad, albeit in a different way.

> [@DANewton](#):
>
> If we’re limited to the generic table, what’s the best way to break up the table?

If you're going to use the historian then you can't really do much. If you can potentially move over to transaction groups then you have more control over how and where things are stored.

> [@DANewton](#):
>
> Is there a way to optimize this table?

There are ways to optimize the queries. It depends a lot on the database you're using. @pturmel's suggestions 2,3, & 4 are probably the best places to start.

You may also find the discussion here interesting, it isn't about exactly the same thing but definitely has some insight into your issue.

> [@Historian Table Partitioning](http://forum.inductiveautomation.com/t/historian-table-partitioning/19155/12):
>
> I haven’t had to optimize the Historian, as I don’t ever put millions of rows in it. /-: But I’d start with studying all of the indices on the tables to make sure the queries are optimizable and optimization statistics are present. I would make sure there is a [BRIN index](https://www.postgresql.org/docs/9.5/static/indexes-types.html) on the t\_stamp column, and a separate b-tree index on the tag id column. Recommended indexing would vary with DB brand, of course. Larger partitions should be tolerable with proper indices. The [EXPLAIN ANALYZE …](https://www.postgresql.org/docs/9.5/static/sql-explain.html) command wi…

---

_[View the full topic](https://forum.inductiveautomation.com/t/store-forward-memory-buffer-and-local-cache-overflow/42355)._