Clarify SQL Servers Indexed Views (#4425)

SQL Server provides something similiar but with a distinct feature set from Postgres Materialized Views. Pointing out the difference, especially between automatic and manual refreshs, which can be a deal breaker.

Co-authored-by: Shay Rojansky <roji@roji.org>

entity-framework/core/performance/modeling-for-performance.md

@@ -29,11 +29,13 @@ One way to do this, is to perform the update yourself, via the regular EF Core A
 
 For more perf-sensitive applications, database triggers can be defined to automatically perform the recalculation in the database. This saves the extra database roundtrips, automatically occurs within the same transaction as the main update, and can be simpler to set up. EF doesn't provide any specific API for creating or maintaining triggers, but it's perfectly fine to [create an empty migration and add the trigger definition via raw SQL](xref:core/managing-schemas/migrations/managing#arbitrary-changes-via-raw-sql).
 
-### Materialized views
+### Materialized/indexed views
 
-Materialized views are similar to regular views, except that their data is stored on disk ("materialized"), rather than calculated every time when the view is queried. This tool is useful when you don't want to simply add a single cache column to an existing database, but rather want to cache the entire resultset of a complicated and expensive query's results, just as if it were a regular table; these results can then be queried very cheaply without any computation or joins happening. Unlike computed columns, materialized views aren't automatically updated when their underlying tables change - they must be manually refreshed. If the cached data can lag, refreshing the view can be done via a timer; another option is to set up database triggers to review a materialized view once certain database events occur.
+Materialized (or indexed) views are similar to regular views, except that their data is stored on disk ("materialized"), rather than calculated every time the view is queried. Such views are conceptually similar to stored computed columns, as they cache the results of potentially expensive calculations; however, they cache an entire query's resultset instead of a single column. Materialized views can be queried just like any regular table, and since they are cached on disk, such queries execute very quickly and cheaply without havnig to constantly perform the expensive calculations of the query which defines the view.
 
-EF doesn't currently provide any specific API for creating or maintaining views, materialized or otherwise; but it's perfectly fine to [create an empty migration and add the view definition via raw SQL](xref:core/managing-schemas/migrations/managing#arbitrary-changes-via-raw-sql).
+Specific support for materialized views varies across databases. In some databases (e.g. [PostgreSQL](https://www.postgresql.org/docs/current/rules-materializedviews.html)), materialized views must be manually refreshed in order for their values to be synchronized with their underlying tables. This is typically done via a timer - in cases where some data lag is acceptable - or via a trigger or stored procedure call in specific conditions. [SQL Server Indexed Views](https://learn.microsoft.com/sql/relational-databases/views/create-indexed-views), on the other hand, are automatically updated as their underlying tables are modified; this ensures that the view always shows the latest data, at the cost of slower updates. In addition, SQL Server Index Views have various restrictions on what they support; consult the [documentation](https://learn.microsoft.com/sql/relational-databases/views/create-indexed-views) for more information.
+
+EF doesn't currently provide any specific API for creating or maintaining views, materialized/indexed or otherwise; but it's perfectly fine to [create an empty migration and add the view definition via raw SQL](xref:core/managing-schemas/migrations/managing#arbitrary-changes-via-raw-sql).
 
 ## Inheritance mapping