@valiro21 ,

Yes, your understanding of automatic detection of new rows and incremental updates is correct.  

There is a list of operators supported by incremental refresh: ensure that the MV query complies with it. Otherwise, it will fall back to full recompute.

Leverage EXPLAIN CREATE MATERIALIZED VIEW to validate if the query definition is eligible for incremental refresh.

There are other scenarios where refresh may fall back to full recompute (for example, if there were too many changes in the source tables). Follow these good practices:

• Decompose Complex MVs: Split large, complex MVs into multiple smaller ones. Excessive joins or deeply nested operators can sometimes exceed the complexity threshold for incrementalization.
• Increase Update Frequency: If source tables change significantly between runs, the model may determine a full recompute is cheaper. If you see CHANGESET_SIZE_THRESHOLD_EXCEEDED in your logs, try running updates more frequently to reduce the volume of changes per update.
• Ensure Deletion Vectors and Row-Level Tracking are enabled on your source tables: Deletion vectors minimize the changeset size, and row-level tracking is a prerequisite for incrementalizing certain operators.

Finally, you can force incremental refresh instead of relying on an automatic choice. 

You can monitor the refresh strategy (incremental or full recompute), as well as the reason why it was chosen, in the event log.

Best regards,