Hi Abin,
it is possible to measure. Create two similar tables - one set and one multiset, with the same data. Insert same new data into both tables. Ant then measure CPU consumption in the DBQL journal, in the AMPCpuTime field. Even though the Explains are the same, the CPU consumption would probably be different due to duplicate checks.
Because of the AMP level mechanics mensioned above, the duplicate check does not directly depend on how big the table is. Rather than that, it depends on the demographics of the Primary Index. If it is almost unique, then the duplicate checks are reasonable. Because you have to compare the rows only with the same PI value. However, if there are PI values with high numbers of rows per value, then the insertion of a new row enforces the check with many rows with the same PI. That's CPU intensive.
Should you have DBQL results that would prove otherwise, please do not hesitate to share.
Thank you,
Regards,
Vlad.
Hi Abin,
it is possible to measure. Create two similar tables - one set and one multiset, with the same data. Insert same new data into both tables. Ant then measure CPU consumption in the DBQL journal, in the AMPCpuTime field. Even though the Explains are the same, the CPU consumption would probably be different due to duplicate checks.
Because of the AMP level mechanics mensioned above, the duplicate check does not directly depend on how big the table is. Rather than that, it depends on the demographics of the Primary Index. If it is almost unique, then the duplicate checks are reasonable. Because you have to compare the rows only with the same PI value. However, if there are PI values with high numbers of rows per value, then the insertion of a new row enforces the check with many rows with the same PI. That's CPU intensive.
Should you have DBQL results that would prove otherwise, please do not hesitate to share.
Thank you,
Regards,
Vlad.