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?
Simple. SQL IDE like Datagrip or the native tools for a particular DB platform don't convert everything to JSON.
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.
It is probably not converting everything to JSON, but delivering optimized HTML to directly populate the table.
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.)
Is the Table virtualized turned on? Probably not for your use cases, but I find that that helps. Using paging as well...
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?
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.
is this module only applicable to Vision?
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.
I am trying to display a large amount of history data from Wonderware Historian in Perspective table and chart. is this a proper approach?
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.
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.
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?
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.
You might want to check out this post for ideas:
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}
thank you! I will try this approach.
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.