Hi Kévin,

A custom operator is indeed a great way to extend, transform, and manipulate data. A custom operator will, for example, do something with each row (in your case, probably adding a value to the added column).

Unless some expensive operations are needed to generate that value, the impact of a custom operator on performance should not be significant.

However, there is one important sidenote: With GQI and the DOM Instances data source in this case, we try to fetch the data as efficiently as possible. This means that if a user adds a filter operator in the query or uses the filter option in the table header, we try to forward that filter as close to the database as possible. But if there is a custom operator in your query between the data source and the filter operator, we can't know if we are allowed to forward the filtering to the database. Because of that, we need to go into post-filtering mode, which means that GQI will do the filtering in memory, which will be less efficient.

To address this, we introduced the feature described in the following tutorial: https://docs.dataminer.services/user-guide/Advanced_Modules/Dashboards_and_Low_Code_Apps/GQI/Extensions/Custom_Operator/Tutorials/Custom_Operator_Tutorial.html
Through this mechanism, you can indicate that filter operators might be forwarded if applicable.

Does the above mentioned reason explain why the performance has decreased significantly? If so, I would suggest to apply the optimization as shown in the tutorial.

Feel free to let me know if anything is unclear, I can further assist you.

Best regards, Ward