Could a Derived DateTime Partition Column Affect Incremental Refresh Performance?

Hi Team,

I noticed one key difference between our Missed Utterances report and our other reports that use Incremental Refresh.

For most of our reports, the partition column comes directly from the DATE_TIME dimension table:

dt.TXN_DATE AS IXN_SUBHOUR_DATE

This is obtained through a simple join using DATE_TIME_KEY.

However, in the Missed Utterances report, the partition column is derived as follows:

CAST(
    START_TIME AT TIME ZONE 'UTC'
    AT TIME ZONE 'Pacific Standard Time'
AS DATETIME) AS DATE_TIME

The same Incremental Refresh configuration works successfully in our DEV environment, but in PROD the first Incremental Refresh runs for several hours and eventually fails with a SQL Execution Timeout, while a full refresh in Power BI Desktop completes successfully.

My question is:

1. Could using a derived DateTime expression (with AT TIME ZONE and CAST) as the Incremental Refresh partition column affect query folding, SQL optimization, or execution plans compared to using a DateTime column directly from the database?

2. Could this prevent SQL Server from using an Index Seek and instead cause an Index Scan or Table Scan during Incremental Refresh?

3. Is it considered a best practice to expose the converted DateTime as a physical column or view column in SQL Server rather than calculating it in the view used by Power BI?

I'd appreciate any guidance or recommendations based on your experience.

Thank you.