Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hi everyone,
I'm having a small problem with a Qlik Cloud application that's exceeding its quota by only 1,6 MB.
I'm looking for tips on how to reduce its size without affecting the number of rows in the tables.
Do you know if there's a way to detect unused fields in Qlik Cloud?
Any suggestions for methods, tools, or ideas to free up some space are welcome.
Thank you in advance for your help!
There is a document analyzer - here a starting point:
Solved: Qliksense Document Analyzer - Qlik Community - 1986299
Other considerations may go to split fields with many distinct values into several fields, like a timestamp into a date and a time field and/or removing row-level formatting by date/time fields.
Hi,
I would do the following as well.
1. Num all dates eg 2025-09-02 becomes 45902. This will half the bit size of each record.
2. Then convert time stamp data in a seperate field as a demical 5 or 6 num or if only the hour is needed, convert to the hour only.
I found this to be a quick fix with results between 8-23 percent shrinkage.
Regards
Sean
> Do you know if there's a way to detect unused fields in Qlik Cloud?
I'd use this: https://github.com/eapowertools/qlik-field-usage-automation. It's less robust on recommendations than https://motio.com/qsda-pro/ but it's free
Hi @herard_bertrand ,
Here's a few things that you can do to reduce the memory usage:
Use the App Analyzer app to analyze all the fields and their impact to the overall memory usage. This app can be installed using the Monitoring Apps automation.
I'll send a screenshot below so you can see what to expect. That will help you get started on the size reduction.
Let me know how it goes.
"Num all dates eg 2025-09-02 becomes 45902. This will half the bit size of each record."
I'm not sure that this is correct for all cases of dates. As I understand it, dates that are stored as implied dual fields will only hold the numerical integer in memory but because the "string" representation is defined only by a pattern such as 'YYYY-MM-DD'. My understanding ia that youbwill not win much by changing such a date into num. In think @rwunderlich 8 year old blog post on dual value storage can be a helpful read for related to this.
I've had some quite big savings on rounding numeric currency values, two decimals is often enough. It is not always an accepted, but for many cases the last decimals are of less importance.
Round(amount_eur, 1/100) as amount_eur