# Perspective Table Performance Issue for Large Dataset

**URL:** <https://forum.inductiveautomation.com/t/perspective-table-performance-issue-for-large-dataset/85271>\
**Category:** Ignition Early Access\
**Tags:** perspective\
**Created:** [February 6, 2024, 6:36am UTC](https://forum.inductiveautomation.com/t/perspective-table-performance-issue-for-large-dataset/85271 "2024-02-06T06:36:03Z")\
**Posts on this page:** 19\
**Page:** 1

<div class="post-metadata">

**Author:** ![nader.chinichian](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nader.chinichian/32/9261_2.png) [@nader.chinichian](https://forum.inductiveautomation.com/u/nader.chinichian)\
**Post date:** [February 6, 2024, 6:36am UTC](https://forum.inductiveautomation.com/t/perspective-table-performance-issue-for-large-dataset/85271/1 "2024-02-06T06:36:03Z")

</div>

I wonder why we see performance issues when we have a dataset size of more than 3000 rows in Perspective Table which causes the page to freeze, gateway crash, and so on, but the SQL IDE tools can simply read and display more than 20000 rows easily.  
What is the mean difference between these two?

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [February 6, 2024, 1:00pm UTC](https://forum.inductiveautomation.com/t/perspective-table-performance-issue-for-large-dataset/85271/2 "2024-02-06T13:00:10Z")

</div>

Simple. SQL IDE like Datagrip or the native tools for a particular DB platform **don't convert everything to JSON**.

---

<div class="post-metadata">

**Author:** ![nader.chinichian](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nader.chinichian/32/9261_2.png) [@nader.chinichian](https://forum.inductiveautomation.com/u/nader.chinichian)\
**Post date:** [February 6, 2024, 3:04pm UTC](https://forum.inductiveautomation.com/t/perspective-table-performance-issue-for-large-dataset/85271/3 "2024-02-06T15:04:55Z")

</div>

But QuestDB IDE which web base does that.  
DBeaver Docker version is also web base and use JSON  
Also, I remember tables or easychart in Vision have same problem when the dataset is more than 1500 rows.

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [February 6, 2024, 3:20pm UTC](https://forum.inductiveautomation.com/t/perspective-table-performance-issue-for-large-dataset/85271/4 "2024-02-06T15:20:18Z")

</div>

> [@nader.chinichian](#):
>
> But QuestDB IDE which web base does that.

It is probably not converting everything to JSON, but delivering optimized HTML to directly populate the table.

> [@nader.chinichian](#):
>
> tables or easychart in Vision have same problem when the dataset is more than 1500 rows.

Uhm, no. I've delivered many tens of thousands of rows to Vision tables without problems, and **millions** of rows to Vision charts. (Typically need my TS DB Cache module to move such large datasets, but Vision has **no** problem **displaying** them.)

---

<div class="post-metadata">

**Author:** ![YF129701](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/yf129701/32/60498_2.png) [@YF129701](https://forum.inductiveautomation.com/u/YF129701)\
**Post date:** [February 6, 2024, 5:12pm UTC](https://forum.inductiveautomation.com/t/perspective-table-performance-issue-for-large-dataset/85271/5 "2024-02-06T17:12:59Z")

</div>

Is the Table virtualized turned on? Probably not for your use cases, but I find that that helps. Using paging as well...

---

<div class="post-metadata">

**Author:** ![nader.chinichian](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nader.chinichian/32/9261_2.png) [@nader.chinichian](https://forum.inductiveautomation.com/u/nader.chinichian)\
**Post date:** [February 7, 2024, 7:46am UTC](https://forum.inductiveautomation.com/t/perspective-table-performance-issue-for-large-dataset/85271/7 "2024-02-07T07:46:08Z")

</div>

I wonder how did you load millions of rows in Vision. One thing I saw every time a client loads something big like 3000 rows the RAM usage increases a lot and when the user closes the window the RAM doesn't decrease or decrease a little bit so eventually one day gateway crashes.  
how much Ignition's RAM do you have?

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [February 7, 2024, 1:13pm UTC](https://forum.inductiveautomation.com/t/perspective-table-performance-issue-for-large-dataset/85271/8 "2024-02-07T13:13:07Z")

</div>

You have to chunk the queries. Vision can hold the chunks (and assemble into a full dataset) while the gateway lets them be garbage collected after transmission. Millions of rows in a dataset yields tens or a few hundreds of megabytes in client RAM, which is easily handled by client RAM configuration.

(My Time Series Database Cache Module does this chunking, transmission, and reassembly for you.)

Vision's client RAM usage is totally independent of gateway RAM.

---

<div class="post-metadata">

**Author:** ![jfan](https://avatars.discourse-cdn.com/v4/letter/j/e8c25b/32.png) [@jfan](https://forum.inductiveautomation.com/u/jfan)\
**Post date:** [August 19, 2026, 3:04pm UTC](https://forum.inductiveautomation.com/t/perspective-table-performance-issue-for-large-dataset/85271/9 "2026-08-19T15:04:37Z")

</div>

is this module only applicable to Vision?

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [August 19, 2026, 4:01pm UTC](https://forum.inductiveautomation.com/t/perspective-table-performance-issue-for-large-dataset/85271/10 "2026-08-19T16:01:04Z")

</div>

You can use this module in Perspective, with expression bindings or scripting. It doesn't integrate with the Power Chart or normal history bindings (yet...).

Be aware that using it in gateway scope will hold the gateway-side cache in place. Dataset fragments held by a Vision client (and no other consumers) will be garbage collected on the gateway side in ~ 5 minutes.

---

<div class="post-metadata">

**Author:** ![jfan](https://avatars.discourse-cdn.com/v4/letter/j/e8c25b/32.png) [@jfan](https://forum.inductiveautomation.com/u/jfan)\
**Post date:** [August 19, 2026, 4:03pm UTC](https://forum.inductiveautomation.com/t/perspective-table-performance-issue-for-large-dataset/85271/11 "2026-08-19T16:03:26Z")

</div>

I am trying to display a large amount of history data from Wonderware Historian in Perspective table and chart. is this a proper approach?

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [August 19, 2026, 4:05pm UTC](https://forum.inductiveautomation.com/t/perspective-table-performance-issue-for-large-dataset/85271/12 "2026-08-19T16:05:11Z")

</div>

Is the Wonderware historian exposed as a normal SQL database connection? If so, I would expect it to work. This module does **not** act as a historian layer.

---

<div class="post-metadata">

**Author:** ![jfan](https://avatars.discourse-cdn.com/v4/letter/j/e8c25b/32.png) [@jfan](https://forum.inductiveautomation.com/u/jfan)\
**Post date:** [August 19, 2026, 4:21pm UTC](https://forum.inductiveautomation.com/t/perspective-table-performance-issue-for-large-dataset/85271/13 "2026-08-19T16:21:01Z")

</div>

Yes, the Wonderware historian does expose a normal SQL DB connection where Ignition can run query. Since we will be running and querying the data on the gateway side with Perspective, is this going to still affect performance?

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/b/d/bd3b4791a7d8f68ac9b625a90d0cd98a25e95757.png)

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [August 19, 2026, 6:50pm UTC](https://forum.inductiveautomation.com/t/perspective-table-performance-issue-for-large-dataset/85271/14 "2026-08-19T18:50:07Z")

</div>

> [@jfan](#):
>
> is this going to still affect performance?

In Ignition, the gateway always does all the queries. Caching or not caching does affect performance, but the behavioral differences with my TS DB Cache module between Vision and Perspective will show up in gateway memory usage. If your Wonderware historian is your query bottleneck, and your gateway has plenty of RAM, using my TS DB Cache module may be a substantial performance win.

As with many things in this niche, it depends on your application.

---

<div class="post-metadata">

**Author:** ![jfan](https://avatars.discourse-cdn.com/v4/letter/j/e8c25b/32.png) [@jfan](https://forum.inductiveautomation.com/u/jfan)\
**Post date:** [August 19, 2026, 7:57pm UTC](https://forum.inductiveautomation.com/t/perspective-table-performance-issue-for-large-dataset/85271/15 "2026-08-19T19:57:42Z")

</div>

Always appreciate your help! I will give it a shot.

So the idea of this is that we can query data in chunks, cache data, and then use it in the chart and table? But then if the second bottleneck is the Apex chart displaying a large amount of data, what other ways do we have to resolve it?

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [August 20, 2026, 1:26am UTC](https://forum.inductiveautomation.com/t/perspective-table-performance-issue-for-large-dataset/85271/16 "2026-08-20T01:26:23Z")

</div>

> [@jfan](#):
>
> query data in chunks

The module does the chunking for you. As chunks arrive, the expression binding retriggers to pull in the additional rows.

Getting the data from the query results to the format needed by the chart is not covered by the module.

---

<div class="post-metadata">

**Author:** ![bmusson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bmusson/32/87530_2.png) [@bmusson](https://forum.inductiveautomation.com/u/bmusson)\
**Post date:** [August 20, 2026, 3:18am UTC](https://forum.inductiveautomation.com/t/perspective-table-performance-issue-for-large-dataset/85271/17 "2026-08-20T03:18:39Z")

</div>

> [@jfan](#):
>
> But then if the second bottleneck is the Apex chart displaying a large amount of data, what other ways do we have to resolve it?

You might want to check out this post for ideas:

> [@Musson Industrial’s Embr-Charts Module](https://forum.inductiveautomation.com/t/musson-industrial-s-embr-charts-module/91618/87):
>
> Here's an example of loading extremely large datasets into the chart by bypassing the component props and directly updating the data of the chart instance. I'm generating my data here, but it's not hard to imagine using a query instead. def runAction(self, event): from java.lang import Math component = self.parent.parent.getChild("Chartjs") chart = component.getJavaScriptProxy('chart') elements = self.view.custom.actions.elements chunkSize = self.view.custom.actions.chunkSize c…

---

<div class="post-metadata">

**Author:** ![jfan](https://avatars.discourse-cdn.com/v4/letter/j/e8c25b/32.png) [@jfan](https://forum.inductiveautomation.com/u/jfan)\
**Post date:** [August 20, 2026, 2:53pm UTC](https://forum.inductiveautomation.com/t/perspective-table-performance-issue-for-large-dataset/85271/18 "2026-08-20T14:53:05Z")

</div>

it looks like the module is not working with the Wonderware Historian. no rows returned and also getting this error when trying to get cache data.

WARN

GatewayCache

20Aug2026 10:51:47

ColumnsQuery.run() failure cache GatewayCache("line223", "History", "TagName = 'testData.line223\_test2' AND wwRetrievalMode = 'Delta'", "DateTime"){0x0d906fa1}

DEBUG

GatewayCache

20Aug2026 10:51:47

ColumnsQuery.run() for GatewayCache("line223", "History", "TagName = 'testData.line223\_test2' AND wwRetrievalMode = 'Delta'", "DateTime"){0x0d906fa1}

---

<div class="post-metadata">

**Author:** ![jfan](https://avatars.discourse-cdn.com/v4/letter/j/e8c25b/32.png) [@jfan](https://forum.inductiveautomation.com/u/jfan)\
**Post date:** [August 20, 2026, 2:53pm UTC](https://forum.inductiveautomation.com/t/perspective-table-performance-issue-for-large-dataset/85271/19 "2026-08-20T14:53:21Z")

</div>

thank you! I will try this approach.

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [August 20, 2026, 3:12pm UTC](https://forum.inductiveautomation.com/t/perspective-table-performance-issue-for-large-dataset/85271/20 "2026-08-20T15:12:06Z")

</div>

The module expects the DB to support SQL-standard identifier and value quoting. Send me an email at my support address if you'd like to set up a joint troubleshooting session.
