Single/Multi-threading in QlikViewArticle Number: 000035306 | Last Modified: 2019/01/17
This article provides content from a Community post regarding what is single versus multi-threaded processed in the QlikView product.
You may think from old versions of QlikView that there are single and multi-threat functions in QlikView, like count(distinct..),..., but this had changed and it is not true anymore for the newer releases after QlikView 9.
So, all functions are multi-threaded. There is a wide-spread misconception in the field that some functions are single-threaded and others aren’t. This is wrong. All functions are multi-threaded. See https://community.qlik.com/t5/Qlik-Design-Blog/A-Myth-About-Count-distinct/ba-p/1476053
But there are some operations that are single threaded. It is best described by the picture below:
The first phase – the logical inference – is multithreaded. It just calculates which field values are possible and which are excluded.
The last phase – the aggregation itself – is multithreaded. It performs the actual calculation, e.g. Sum(Sales). Then a long table is split into several chunks and each thread takes care of one of the chunks.
The middle phase is however single threaded, or rather, it has one thread per object on the screen. This means that you can have a pivot table that is single threaded. The single threaded phase figures out which combinations there are to consider in the aggregation. If you have Product as dimension, and Sum(Sales) as measure, this phase finds the combinations between Sales and Product. “Which Product does this sales transaction belong to?” So, this phase builds look-up tables so that a specific Sales record can be attributed to a specific Product. Normally, this is a fast operation, so you don’t even notice that it happens.
- If you have more than one very large fact table
Say that you have four tables: Customer – Order Headers – Order Details – Products, and the two middle ones are large (millions of records). Then it can be expensive to have both Customers and Products in the same calculation, since the Qlik engine on-the-fly needs to generate all combinations between the two large tables. Better then to join the two tables already in the script.
- If you have fields from more than one source table inside your aggregation
Say that you want to calculate Sum(ListPrice*Quantity), and ListPrice and Quantity are in two different tables (Products and Order Details). Then the Qlik engine needs to generate a temporary table with all combinations between the two, in addition to attributing each record in this temporary table to the dimensional values. Better then to move ListPrice to the Order Details table already in the script.
Have a Question?
Search Qlik's Support Knowledge database or request assisted support for highly complex issues.Submit a case
Experiencing a serious issue, please contact us by phone. View phone numbers and hours by region.