Address review feedback

Author: mulander

articles/cosmos-db/postgresql/concepts-colocation.md

@@ -24,7 +24,7 @@ In Azure Cosmos DB for PostgreSQL, a row is stored in a shard if the hash of the
 
 ## A practical example of colocation
 
-Consider the following tables that might be part of a multi-tenant web
+Consider the following tables that might be part of a multitenant web
 analytics SaaS:
 
 ```sql
@@ -153,4 +153,4 @@ In some cases, queries and table schemas must be changed to include the tenant I
 
 ## Next steps
 
-- See how tenant data is colocated in the [multi-tenant tutorial](tutorial-design-database-multi-tenant.md).
+- See how tenant data is colocated in the [multitenant tutorial](tutorial-design-database-multi-tenant.md).

articles/cosmos-db/postgresql/concepts-nodes.md

@@ -78,11 +78,11 @@ When you use Azure Cosmos DB for PostgreSQL, the coordinator node you connect to
 
 A good candidate for local tables would be small administrative tables that don't participate in join queries. An example is a `users` table for application sign-in and authentication.
 
-### Type 4: Local Managed Tables
+### Type 4: Local managed tables
 
-Azure Cosmos DB for PostgreSQL may automatically add local tables to metadata if a foreign key reference exists between a local table and a reference table. Additionally locally managed tables can be manually created by executing [create_reference_table](reference-functions.md#citus_add_local_table_to_metadata) citus_add_local_table_to_metadata function on regular local tables. Tables present in metadata are considered managed tables and can be queried from any node, Citus knows to route to the coordinator to obtain data from the local managed table. Such tables are displayed as local in [citus_tables](reference-metadata.md#distributed-tables-view) view.
+Azure Cosmos DB for PostgreSQL might automatically add local tables to metadata if a foreign key reference exists between a local table and a reference table. Additionally locally managed tables can be manually created by executing [create_reference_table](reference-functions.md#citus_add_local_table_to_metadata) citus_add_local_table_to_metadata function on regular local tables. Tables present in metadata are considered managed tables and can be queried from any node, Citus knows to route to the coordinator to obtain data from the local managed table. Such tables are displayed as local in [citus_tables](reference-metadata.md#distributed-tables-view) view.
 
-### Type 5: Schema Tables
+### Type 5: Schema tables
 
 With [schema-based sharding](concepts-sharding-models.md#schema-based-sharding) introduced in Citus 12.0, distributed schemas are automatically associated with individual colocation groups. Tables created in those schemas are automatically converted to colocated distributed tables without a shard key. Such tables are considered schema tables and are displayed as schema in [citus_tables](reference-metadata.md#distributed-tables-view) view.
 

articles/cosmos-db/postgresql/concepts-sharding-models.md

@@ -36,7 +36,7 @@ Drawbacks:
 
 ## Schema-based sharding
 
-Available with Citus 12.0 in Azure Cosmos DB for PostgreSQL, schema-based sharding is the shared database, separate schema model, the schema becomes the logical shard within the database. Multi-tenant apps can use a schema per tenant to easily shard along the tenant dimension. Query changes aren't required and the application only needs a small modification to set the proper search_path when switching tenants. Schema-based sharding is an ideal solution for microservices, and for ISVs deploying applications that can't undergo the changes required to onboard row-based sharding.
+Available with Citus 12.0 in Azure Cosmos DB for PostgreSQL, schema-based sharding is the shared database, separate schema model, the schema becomes the logical shard within the database. Multitenant apps can use a schema per tenant to easily shard along the tenant dimension. Query changes aren't required and the application only needs a small modification to set the proper search_path when switching tenants. Schema-based sharding is an ideal solution for microservices, and for ISVs deploying applications that can't undergo the changes required to onboard row-based sharding.
 
 Benefits:
 

articles/cosmos-db/postgresql/concepts-upgrade.md

@@ -16,7 +16,7 @@ ms.date: 10/01/2023
 The Azure Cosmos DB for PostgreSQL managed service can handle upgrades of both the
 PostgreSQL server, and the Citus extension. All clusters are created with [the latest Citus version](./reference-extensions.md#citus-extension) available for the major PostgreSQL version you select during cluster provisioning. When you select a PostgreSQL version such as PostgreSQL 15 for in-place cluster upgrade, the latest Citus version supported for selected PostgreSQL version is going to be installed. 
 
-If you need to upgrade the Citus version only, you can do so by using an in-place upgrade. For instance, you may want to upgrade Citus 11.0 to Citus 11.3 on your PostgreSQL 14 cluster without upgrading Postgres version. 
+If you need to upgrade the Citus version only, you can do so by using an in-place upgrade. For instance, you might want to upgrade Citus 11.0 to Citus 11.3 on your PostgreSQL 14 cluster without upgrading Postgres version. 
 
 ## Upgrade precautions
 
@@ -36,8 +36,8 @@ Noteworthy Citus 12 changes:
 
 Noteworthy Citus 11 changes:
 
-* Table shards may disappear in your SQL client. Their visibility
-  is now controlled by
+* Table shards might disappear in your SQL client. You can control their visibility
+  using
   [citus.show_shards_for_app_name_prefixes](reference-parameters.md#citusshow_shards_for_app_name_prefixes-text).
 * There are several [deprecated
   features](https://www.citusdata.com/updates/v11-0/#deprecated-features).

articles/cosmos-db/postgresql/howto-useful-diagnostic-queries.md

@@ -15,7 +15,7 @@ ms.date: 10/01/2023
 
 ## Finding which node contains data for a specific tenant
 
-In the multi-tenant use case, we can determine which worker node contains the
+In the multitenant use case, we can determine which worker node contains the
 rows for a specific tenant.  Azure Cosmos DB for PostgreSQL groups the rows of distributed
 tables into shards, and places each shard on a worker node in the cluster. 
 
@@ -91,7 +91,7 @@ Each distributed table has a "distribution column." (For
 more information, see [Distributed Data
 Modeling](howto-choose-distribution-column.md).) It can be
 important to know which column it is. For instance, when joining or filtering
-tables, you may see error messages with hints like, "add a filter to the
+tables, you might see error messages with hints like, "add a filter to the
 distribution column."
 
 The `pg_dist_*` tables on the coordinator node contain diverse metadata about

articles/cosmos-db/postgresql/quickstart-build-scalable-apps-overview.md

@@ -18,7 +18,7 @@ ms.date: 10/01/2023
 There are three steps involved in building scalable apps with Azure Cosmos DB for PostgreSQL:
 
 1. Classify your application workload. There are use-case where Azure Cosmos DB for PostgreSQL
-   shines: multi-tenant SaaS, microservices, real-time operational analytics, and high
+   shines: Multitenant SaaS, microservices, real-time operational analytics, and high
    throughput OLTP. Determine whether your app falls into one of these categories.
 2. Based on the workload, use [schema-based sharding](concepts-sharding-models.md#schema-based-sharding) or identify the optimal shard key for the distributed
    tables. Classify your tables as reference, distributed, or local. 

articles/cosmos-db/postgresql/reference-functions.md

@@ -32,7 +32,7 @@ Converts existing regular schemas into distributed schemas. Distributed schemas
 
 **schemaname:** Name of the schema, which needs to be distributed.
 
-#### Return Value
+#### Return value
 
 N/A
 
@@ -54,7 +54,7 @@ Converts an existing distributed schema back into a regular schema. The process
 
 **schemaname:** Name of the schema, which needs to be distributed.
 
-#### Return Value
+#### Return value
 
 N/A
 
@@ -119,7 +119,7 @@ or colocation group, use the [alter_distributed_table](#alter_distributed_table)
 Possible values for `shard_count` are between 1 and 64000. For guidance on
 choosing the optimal value, see [Shard Count](howto-shard-count.md).
 
-#### Return Value
+#### Return value
 
 N/A
 
@@ -175,7 +175,7 @@ distribution.
 **table_name:** Name of the distributed table whose local counterpart on the
 coordinator node should be truncated.
 
-#### Return Value
+#### Return value
 
 N/A
 
@@ -198,7 +198,7 @@ worker node.
 **table\_name:** Name of the small dimension or reference table that
 needs to be distributed.
 
-#### Return Value
+#### Return value
 
 N/A
 
@@ -225,7 +225,7 @@ When you undistribute the table, Citus removes the resulting local tables from m
 
 **cascade\_via\_foreign\_keys**: (Optional) When this argument set to “true,” citus_add_local_table_to_metadata adds other tables that are in a foreign key relationship with given table into metadata automatically. Use caution with this parameter, because it can potentially affect many tables.
 
-#### Return Value
+#### Return value
 
 N/A
 
@@ -261,7 +261,7 @@ tables that were previously colocated with the table, and the colocation will
 be preserved. If it is "false", the current colocation of this table will be
 broken.
 
-#### Return Value
+#### Return value
 
 N/A
 
@@ -300,7 +300,7 @@ This function doesn't move any data around physically.
 If you want to break the colocation of a table, you should specify
 `colocate_with => 'none'`.
 
-#### Return Value
+#### Return value
 
 N/A
 
@@ -357,7 +357,7 @@ undistribute_table also undistributes all tables that are related to table_name
 through foreign keys. Use caution with this parameter, because it can
 potentially affect many tables.
 
-#### Return Value
+#### Return value
 
 N/A
 
@@ -406,7 +406,7 @@ a distributed table (or, more generally, colocation group), be sure to name
 that table using the `colocate_with` parameter. Then each invocation of the
 function will run on the worker node containing relevant shards.
 
-#### Return Value
+#### Return value
 
 N/A
 
@@ -460,11 +460,11 @@ overridden with these GUCs:
 **table_name:** Name of the columnar table.
 
 **chunk_row_count:** (Optional) The maximum number of rows per chunk for
-newly inserted data. Existing chunks of data won't be changed and may have
+newly inserted data. Existing chunks of data won't be changed and might have
 more rows than this maximum value. The default value is 10000.
 
 **stripe_row_count:** (Optional) The maximum number of rows per stripe for
-newly inserted data. Existing stripes of data won't be changed and may have
+newly inserted data. Existing stripes of data won't be changed and might have
 more rows than this maximum value. The default value is 150000.
 
 **compression:** (Optional) `[none|pglz|zstd|lz4|lz4hc]` The compression type
@@ -500,7 +500,7 @@ The alter_table_set_access_method() function changes access method of a table
 
 **access_method:** Name of the new access method.
 
-#### Return Value
+#### Return value
 
 N/A
 
@@ -529,7 +529,7 @@ will contain the point end_at, and no later partitions will be created.
 **start_from:** (timestamptz, optional) pick the first partition so that it
 contains the point start_from. The default value is `now()`.
 
-#### Return Value
+#### Return value
 
 True if it needed to create new partitions, false if they all existed already.
 
@@ -562,7 +562,7 @@ be partitioned on one column, of type date, timestamp, or timestamptz.
 **older_than:** (timestamptz) drop partitions whose upper range is less than or
 equal to older_than.
 
-#### Return Value
+#### Return value
 
 N/A
 
@@ -591,7 +591,7 @@ or equal to older_than.
 **new_access_method:** (name) either 'heap' for row-based storage, or
 'columnar' for columnar storage.
 
-#### Return Value
+#### Return value
 
 N/A
 
@@ -623,7 +623,7 @@ doesn't work for the append distribution.
 
 **distribution\_value:** The value of the distribution column.
 
-#### Return Value
+#### Return value
 
 The shard ID Azure Cosmos DB for PostgreSQL associates with the distribution column value
 for the given table.
@@ -655,7 +655,7 @@ column](howto-choose-distribution-column.md).
 **column\_var\_text:** The value of `partkey` in the `pg_dist_partition`
 table.
 
-#### Return Value
+#### Return value
 
 The name of `table_name`'s distribution column.
 
@@ -689,7 +689,7 @@ visibility map and free space map for the shards.
 
 **logicalrelid:** the name of a distributed table.
 
-#### Return Value
+#### Return value
 
 Size in bytes as a bigint.
 
@@ -714,7 +714,7 @@ excluding indexes (but including TOAST, free space map, and visibility map).
 
 **logicalrelid:** the name of a distributed table.
 
-#### Return Value
+#### Return value
 
 Size in bytes as a bigint.
 
@@ -739,7 +739,7 @@ distributed table, including all indexes and TOAST data.
 
 **logicalrelid:** the name of a distributed table.
 
-#### Return Value
+#### Return value
 
 Size in bytes as a bigint.
 
@@ -766,7 +766,7 @@ all stats, call both functions.
 
 N/A
 
-#### Return Value
+#### Return value
 
 None
 
@@ -779,7 +779,7 @@ host names and port numbers.
 
 N/A
 
-#### Return Value
+#### Return value
 
 List of tuples where each tuple contains the following information:
 
@@ -833,7 +833,7 @@ placement is present (\"target\" node).
 **target\_node\_port:** The port on the target worker node on which the
 database server is listening.
 
-#### Return Value
+#### Return value
 
 N/A
 
@@ -893,7 +893,7 @@ command. The possible values are:
 > -   `block_writes`: Use COPY (blocking writes) for tables lacking
 >     primary key or replica identity.
 
-#### Return Value
+#### Return value
 
 N/A
 
@@ -927,7 +927,7 @@ The "by\_shard\_count" strategy is appropriate under these circumstances:
 
 If any of these assumptions don’t hold, then rebalancing “by_shard_count” can result in a bad plan.
 
-The default rebalancing starategy is “by_disk_size”. You can always customize the strategy, using the `rebalance_strategy` parameter.
+The default rebalancing strategy is “by_disk_size”. You can always customize the strategy, using the `rebalance_strategy` parameter.
 
 It's advisable to call
 [get_rebalance_table_shards_plan](#get_rebalance_table_shards_plan) before
@@ -975,7 +975,7 @@ other shards.
 If this argument is omitted, the function chooses the default strategy, as
 indicated in the table.
 
-#### Return Value
+#### Return value
 
 N/A
 
@@ -1010,7 +1010,7 @@ The same arguments as rebalance\_table\_shards: relation, threshold,
 max\_shard\_moves, excluded\_shard\_list, and drain\_only. See
 documentation of that function for the arguments' meaning.
 
-#### Return Value
+#### Return value
 
 Tuples containing these columns:
 
@@ -1032,7 +1032,7 @@ executed by `rebalance_table_shards()`.
 
 N/A
 
-#### Return Value
+#### Return value
 
 Tuples containing these columns:
 
@@ -1092,7 +1092,7 @@ precisely the cumulative shard cost should be balanced between nodes
 minimum value allowed for the threshold argument of
 rebalance\_table\_shards(). Its default value is 0
 
-#### Return Value
+#### Return value
 
 N/A
 
@@ -1107,7 +1107,7 @@ when rebalancing shards.
 
 **name:** the name of the strategy in pg\_dist\_rebalance\_strategy
 
-#### Return Value
+#### Return value
 
 N/A
 
@@ -1142,7 +1142,7 @@ SELECT * from citus_remote_connection_stats();
 ### isolate\_tenant\_to\_new\_shard
 
 This function creates a new shard to hold rows with a specific single value in
-the distribution column. It's especially handy for the multi-tenant
+the distribution column. It's especially handy for the multitenant
 use case, where a large tenant can be placed alone on its own shard and
 ultimately its own physical node.
 
@@ -1157,7 +1157,7 @@ assigned to the new shard.
 from all tables in the current table's [colocation
 group](concepts-colocation.md).
 
-#### Return Value
+#### Return value
 
 **shard\_id:** The function returns the unique ID assigned to the newly
 created shard.