I had a similar problem where the load from the QVD included several manipulations of the incoming data. The following snippet illustrates my solution, loading to a temporary table and then reloading with my data manipulation - in your case you'd get the incremental data in the second load:
// Load base incident data
// Reload incident data for manipulation
If(IsNull(CausedByID), -99, If(CausedByID = 0, -99, CausedByID)) AS CausedByID,
If(IsNull(POSuiteHierarchyCatID), -99, If(POSuiteHierarchyCatID = 0, -99, If(Trim(POSuiteHierarchyCatID) = '', -99, POSuiteHierarchyCatID))) AS POSuiteHierarchyCatID,
If(IsNull(POSuitesOtherCatID), -99, If(POSuitesOtherCatID = 0, -99, If(Trim(POSuitesOtherCatID) = '', -99, POSuitesOtherCatID))) AS POSuitesOtherCatID,
Trim(LoggedByFirstname & ' ' & LoggedByLastName) AS LoggedByName,
DROP TABLE TmpIncidents;
In that case try putting the WHERE clause on the second load and not on the load from QVD.
The important point is that to get an optimised load from a QVD you mustn't do anything to the data during that load (including looking at it, which is what you're effectively doing by restricting it with the WHERE clause).
I just wondered if you ever found a solution to this problem?? I have the exact same thing happening - version 7.51 on a 32-bit server. Straight load of a qvd - LOAD * FROM xxx.qvd - no WHERE clause or data manipulation. It gets to record 1,173,648 int the qvd within a couple of seconds, then stops. It is not hung - every 5 to 10 minutes it will progress another few thousand records. It's using 25% of the CPU, as you said.
Even odder- if I specify the fields to load and exclude 5 specific fields (out of 19 fields), the data loads in seconds. All 5 fields are fully populated with data - basic Text information.