Qlik Community

QlikView App Dev

Discussion Board for collaboration related to QlikView App Development.

Announcements
QlikWorld 2022, LIVE in Denver CO., May 16-19, 2022. REGISTER NOW TO RECEIVE EARLY BIRD PRICING
cancel
Showing results for 
Search instead for 
Did you mean: 
paulwalker
Creator II
Creator II

Qvd Vs Resident load

Hi Community,

Which one is better performance in loading time

and

which one is fast loading.

Thanks in Advance......

9 Replies
its_anandrjs

QVD is much faster then other load because in QVD data is in the compressed format. But the resident load is with in the application and resident load depends on the other table data that is in the resident table or any other qvd may be and if it joins or concatenate to the other table it may cause to increase the load depends on the key it is unique or duplicate. If it is duplicate then data increases and also load time increases.

1. Depends on the data load and condition in the table load if we say about the resident load if there are any conditional loads then time increases.

2. If we use optimized QVD then loading is faster then any other load also compare with the resident tables load.

3. Resident is used for minimum data and minimum rows which is used for mapping the data or mapping loads so data is less there so it loads faster.

Regards

ToniKautto
Employee
Employee

Data in a QVD file is structured so that QlikView can load the content directly into memory. This is the quickest way to load data into a QlikView application from an external source.

Very important to notice that this is true when you load the QVD content as it is, without making any changes like data manipulation. If you apply changes to the data the load will be unoptimized, and the load performance can decrease significantly compared to the optimized QVD load.

Once a table is in memory, you can load the content as source into an other table by using resident load. Also in this case the existing data is copied from a table that exists in memory, but it is very unlikely that you copy a resident table without data manipulation, so for that reason the performance should be slower than a optimized QVD load.

It is always recommended to load QVD optimized and then reload it as a resident table for any data manipulation.

Roop
Specialist
Specialist

In genera terms, they are very different. You cannot use a resident load for data that is not already in memory. The QVD load will be for data that generally has been stored previously.

If you were to use QVD load the same way as a resident load you would have to store the results out to the QVD first and this would mean that the process would be slowed.

jagan
MVP
MVP

Hi,

When compared to data load from QVD, resident load is faster.  Because data is already in memory. But you cannot find the difference with less data, if the data is huge may be millions you can find the diff.

Regards,

Jagan.

richard_pearce6
Luminary Alumni
Luminary Alumni

If you need to sort the table you'll have to do a resident load


Richard

ger_alegria
Partner
Partner

QVD is faster than a resident table because is a structured file and you can load into memory. But before load a QVD file you must to generate the QVD file.

cesaraccardi
Specialist
Specialist

Hi Paul,

I would say it depends on your environment. I have noticed that sometimes reloading from QVD (even unoptimized loads applying data transformations) can be more performant than resident loads specially if you are loading tens of millions of rows on a server with limited RAM available. I would suggest testing, if possible, both approaches on a server similar to your production environment because there are many variables that can effect the reloading time like physical resources available (RAM & CPU), disk reading/writing speed, network speed when loading files from remote directories, etc...

Hope this helps,

Cesar

jafari_ervin
Creator III
Creator III

Sometimes if you need to join two or more large table with each other QVD is faster than resident load.

jafari_ervin
Creator III
Creator III