addressed reviewer changes

Author: sarat0681

articles/postgresql/TOC.yml

@@ -542,18 +542,18 @@
       - name: Troubleshoot high memory utilization
         href: flexible-server/how-to-high-memory-utilization.md 
         displayName: High Memory Utilization
-      - name: Troubleshoot high io utilization
+      - name: Troubleshoot High IO utilization
         href: flexible-server/how-to-high-io-utilization.md 
         displayName: High IOPS Utilization
       - name: Troubleshoot autovacuum 
         href: flexible-server/how-to-autovacuum-tuning.md
         displayName: Autovacuum troubleshooting, tuning
-      - name: Bulk Data Load Best Practices 
+      - name: Best practices for bulk data upload 
         href: flexible-server/how-to-bulkload_data.md
-        displayName: Bulk Data Load Best Practices
-      - name: Best Practices For Faster Dump And Restore
+        displayName: Best practices for bulk data upload
+      - name: Best practices for pg_dump and restore
         href: flexible-server/how-to-pgdump-restore.md
-        displayName: Best Practices For Faster Dump And Restore
+        displayName: Best practices for pg_dump and restore
   - name: How-to guides
     items:
     - name: Manage a server

articles/postgresql/flexible-server/how-to-bulkload_data.md renamed to articles/postgresql/flexible-server/how-to-bulk-load-data.md

@@ -1,5 +1,5 @@
 ---
-title: Bulk Data Uploads
+title: Bulk Data Uploads For Azure Database for PostgreSQL - Flexible Server
 description: Best practices to bulk load data in Azure Database for PostgreSQL - Flexible Server 
 author: sarat0681
 ms.author: sbalijepalli
@@ -11,7 +11,7 @@ ms.custom: template-how-to #Required; leave this attribute/value as-is.
 ---
 
 
-# Bulk data load best practices
+# Best practices for bulk data upload for Azure Database for PostgreSQL - Flexible Server
 
 There are two types of bulk loads:
 - Initial data load of an empty database
@@ -23,7 +23,7 @@ This article discusses various loading techniques along with best practices when
 
 Performance-wise, the data loading methods arranged in the order of most time consuming to least time consuming is as follows:
 - Single record Insert
-- Batch into 100-1000 rows per commit. One can use transaction block to wrap multiple records per commit [Batch Inserts]
+- Batch into 100-1000 rows per commit. One can use transaction block to wrap multiple records per commit  
 - INSERT with multi row values
 - COPY command
 
@@ -33,27 +33,27 @@ The preferred method to load the data into the database is by copy command. If t
 
 #### Drop indexes
 
-Before an initial data load, it is advised to drop all the indexes in the tables. It is always more efficient to create the indexes after the data load.
+Before an initial data load, it's advised to drop all the indexes in the tables. It's always more efficient to create the indexes after the data load.
 
 #### Drop constraints
 
 ##### Unique key constraints
 
-To achieve strong performance, it's advised to drop unique key constraints before a initial data load and recreate it once the data load is completed. However, be aware that dropping unique key constraints cancels the safeguards against duplicated data.
+To achieve strong performance, it's advised to drop unique key constraints before an initial data load, and recreate it once the data load is completed. However, dropping unique key constraints cancels the safeguards against duplicated data.
 
 ##### Foreign key constraints
 
 It's advised to drop foreign key constraints before initial data load and recreate once data load is completed.
 
-Changing the `session_replication_role` parameter to replica also disables all foreign key checks.However, be aware making the change can leave data in an inconsistent state if not properly used.
+Changing the `session_replication_role` parameter to replica also disables all foreign key checks. However, be aware making the change can leave data in an inconsistent state if not properly used.
 
 #### Unlogged tables
 
-Use of unlogged tables will make data load faster. Data written to unlogged tables is not written to the write-ahead log.
+Use of unlogged tables will make data load faster. Data written to unlogged tables isn't written to the write-ahead log.
 
 The disadvantages of using unlogged tables are
-- They are not crash-safe. An unlogged table is automatically truncated after a crash or unclean shutdown.
-- Data from unlogged tables cannot be replicated to standby servers.
+- They aren't crash-safe. An unlogged table is automatically truncated after a crash or unclean shutdown.
+- Data from unlogged tables can't be replicated to standby servers.
 
 The pros and cons of using unlogged tables should be considered before using in initial data loads.
 
@@ -84,7 +84,7 @@ The maintenance_work_mem can be set to a maximum of 2 GB on a flexible server. `
 
 `checkpoint_timeout`
 
-On the flexible server, the checkpoint_timeout can be increased to maximum 24h from default 5 minutes. It is advised to increase the value to 1 hour before initial data loads on Flexible server.
+On the flexible server, the checkpoint_timeout can be increased to maximum 24 h from default 5 minutes. It's advised to increase the value to 1 hour before initial data loads on Flexible server.
 
 `checkpoint_completion_target`
 
@@ -96,12 +96,12 @@ The max_wal_size can be set to the maximum allowed value on the Flexible server,
 
 `wal_compression`
 
-wal_compression can be turned on. Enabling the parameter can reduce the WAL volume without increasing the risk of unrecoverable data corruption, but at the cost of some extra CPU spent on the compression during WAL logging and on the decompression during WAL replay.
+wal_compression can be turned on. Enabling the parameter can have some extra  CPU cost spent on the compression during WAL logging and on the decompression during WAL replay.
 
 
 #### Flexible server recommendations
 
-Before the start of initial data load on a Flexible server, it is recommended to
+Before the start of initial data load on a Flexible server, it's recommended to
 
 - Disable high availability [HA] on the server. You can enable HA once initial load is completed on master/primary.
 - Create read replicas after initial data load is completed.
@@ -118,7 +118,7 @@ Sets the maximum number of workers that the system can support for parallel quer
 
 `max_parallel_maintenance_workers`
 
-Controls the maximum number of worker process, which can be used to CREATE INDEX.
+Controls the maximum number of worker processes, which can be used to CREATE INDEX.
 
 One could also create the indexes by making recommended settings at the session level. An example of how it can be done at the session level is shown below:
 
@@ -133,7 +133,7 @@ CREATE INDEX test_index ON test_table (test_column);
 
 #### Table partitioning
 
-It is always recommended to partition large tables. Some advantages of partitioning, especially during incremental loads:
+It's always recommended to partition large tables. Some advantages of partitioning, especially during incremental loads:
 - Creation of new partitions based on the new deltas makes it efficient to add new data to the table.
 - Maintenance of tables becomes easier. One can drop a partition during incremental data loads avoiding time-consuming deletes on large tables.
 - Autovacuum would be triggered only on partitions that were changed or added during incremental loads, which make maintaining statistics on the table easier.
@@ -145,7 +145,7 @@ Monitoring and maintaining table statistics is important for query performance o
 #### Index creation on foreign key constraints
 
 Creating indexes on foreign keys in the child tables would be beneficial in the following scenarios:
-- Data updates or deletions in the parent table. When data is updated or deleted in the parent table lookups would be performed on the child table.To make lookups faster you could index foreign keys on the child table.
+- Data updates or deletions in the parent table. When data is updated or deleted in the parent table lookups would be performed on the child table. To make lookups faster, you could index foreign keys on the child table.
 - Queries, where we see join between parent and child tables on key columns.
 
 #### Unused indexes
@@ -235,7 +235,7 @@ SELECT round (pg_wal_lsn_diff('LSN value when run second time','LSN value when r
 
 `wal_compression`
 
-wal_compression can be turned on. Enabling the parameter can reduce the WAL volume without increasing the risk of unrecoverable data corruption, but at the cost of some extra CPU spent on the compression during WAL logging and on the decompression during WAL replay.
+wal_compression can be turned on. Enabling the parameter can have some extra  CPU cost spent on the compression during WAL logging and on the decompression during WAL replay.
 
 
 ## Next steps

articles/postgresql/flexible-server/how-to-high-io-utilization.md

@@ -1,5 +1,5 @@
 ---
-title: High IOPS Utilization
+title: High IOPS Utilization for Azure Database for PostgreSQL - Flexible Server
 description: Troubleshooting guide for high IOPS utilization in Azure Database for PostgreSQL - Flexible Server 
 author: sarat0681
 ms.author: sbalijepalli
@@ -9,7 +9,7 @@ ms.date: 08/16/2022
 ms.custom: template-how-to #Required; leave this attribute/value as-is.
 ---
 
-# Troubleshoot high IOPS utilization in Azure Database for PostgreSQL - Flexible Server
+# Troubleshoot high IOPS utilization for Azure Database for PostgreSQL - Flexible Server
 
 This article shows you how to quickly identify the root cause of high IOPS utilization and possible remedial actions to control IOPS utilization when using [Azure Database for PostgreSQL - Flexible Server](overview.md). 
 
@@ -19,15 +19,15 @@ In this article, you learn:
 - How to identify root causes, such as long-running queries, checkpoint timings, disruptive autovacuum daemon process, and high storage utilization.
 - How to resolve high IO utilization using Explain Analyze, tune checkpoint-related server parameters, and tune autovacuum daemon.
 
-### Tools to identify high IO utilization
+## Tools to identify high IO utilization
 
 Consider these tools to identify high IO utilization.
 
-#### Azure metrics
+### Azure metrics
 
 Azure Metrics is a good starting point to check the IO utilization for the definite date and period. Metrics give information about the time duration the IO utilization is high. Compare the graphs of Write IOPs, Read IOPs, Read Throughput, and Write Throughput to find out times when the workload caused high IO utilization. For proactive monitoring, you can configure alerts on the metrics. For step-by-step guidance, see [Azure Metrics](./howto-alert-on-metrics.md).
 
-#### Query store
+### Query store
 
 Query Store automatically captures the history of queries and runtime statistics and retains them for your review. It slices the data by time to see temporal usage patterns. Data for all users, databases, and queries is stored in a database named azure_sys in the Azure Database for PostgreSQL instance. For step-by-step guidance, see [Query Store](./concepts-query-store.md).
 
@@ -38,7 +38,7 @@ select * from query_store.qs_view qv where is_system_query is FALSE
 order by blk_read_time + blk_write_time  desc limit 5;
 ```
 
-#### pg_stat_statements
+### pg_stat_statements
 
 The pg_stat_statements extension helps identify queries that consume IO on the server.
 
@@ -54,11 +54,11 @@ LIMIT 5;
 > [!NOTE]
 > When using query store or pg_stat_statements for columns blk_read_time and blk_write_time to be populated enable server parameter `track_io_timing`.For more information about the **track_io_timing** parameter, review [Server Parameters](https://www.postgresql.org/docs/current/runtime-config-statistics.html). 
 
-### Identify root causes 
+## Identify root causes 
 
 If IO consumption levels are high in general, the following could be possible root causes: 
 
-#### Long-running transactions  
+### Long-running transactions  
 
 Long-running transactions can consume IO, that can lead to high IO utilization.
 
@@ -71,13 +71,13 @@ WHERE pid <> pg_backend_pid() and state IN ('idle in transaction', 'active')
 ORDER BY duration DESC;   
 ```
 
-#### Checkpoint timings
+### Checkpoint timings
 
 High IO can also be seen in scenarios where a checkpoint is happening too frequently. One way to identify this is by checking the Postgres log file for the following log text "LOG: checkpoints are occurring too frequently."
 
 You could also investigate using an approach where periodic snapshots of `pg_stat_bgwriter` with a timestamp is saved. Using the snapshots saved the average checkpoint interval, number of checkpoints requested and number of checkpoints timed can be calculated. 
 
-#### Disruptive autovacuum daemon process
+### Disruptive autovacuum daemon process
 
 Execute the below query to monitor autovacuum:
 
@@ -90,15 +90,15 @@ The query is used to check how frequently the tables in the database are being v
 **autovacuum_count** : provides number of times the table was vacuumed.    
 **autoanalyze_count**: provides number of times the table was analyzed.   
 
-### Resolve high IO utilization
+## Resolve high IO utilization
 
 To resolve high IO utilization, there are three methods you could employ - using Explain Analyze, terminating long-running transactions, or tuning server parameters.
 
-#### Explain Analyze 
+### Explain Analyze 
 
 Once you identify the query that's consuming high IO, use **EXPLAIN ANALYZE** to further investigate the query and tune it. For more information about the **EXPLAIN ANALYZE** command, review [Explain Plan](https://www.postgresql.org/docs/current/sql-explain.html). 
 
-#### Terminating long running transactions   
+### Terminating long running transactions   
 
 You could consider killing a long running transaction as an option.
 
@@ -113,19 +113,19 @@ ORDER BY duration DESC;
 
 You can also filter by other properties like `usename` (username), `datname` (database name) etc.  
 
-Once you have the session's PID you can terminate using the following query:
+Once you have the session's PID, you can terminate using the following query:
 
 ```sql
 SELECT pg_terminate_backend(pid);
 ```
 
-#### Server parameter tuning
+### Server parameter tuning
 
 If it's observed that the checkpoint is happening too frequently, increase `max_wal_size` server parameter until most checkpoints are time driven, instead of requested. Eventually, 90% or more should be time based, and the interval between two checkpoints is close to the `checkpoint_timeout` set on the server.
 
-##### `max_wal_size`
+`max_wal_size`
 
-Peak business hours is a good time to arrive at `max_wal_size` value. Follow the below listed steps to arrive at a value.
+Peak business hours are a good time to arrive at `max_wal_size` value. Follow the below listed steps to arrive at a value.
 
 Execute the below query to get current WAL LSN, note down the result:
 
@@ -145,23 +145,23 @@ Execute below query that uses the two results to check the difference in GB:
 select round (pg_wal_lsn_diff ('LSN value when run second time', 'LSN value when run first time')/1024/1024/1024,2) WAL_CHANGE_GB;
 ```      
 
-##### `checkpoint_completion_target`
+`checkpoint_completion_target`
 
 A good practice would be to set it to 0.9. As an example, a value of 0.9 for a `checkpoint_timeout` of 5 minutes indicates the target to complete a checkpoint is 270 sec [0.9*300 sec]. A value of 0.9 provides fairly consistent I/O load. An aggressive value of `check_point_completion_target` may result in increased IO load on the server.
 
-##### `checkpoint_timeout`
+`checkpoint_timeout`
 
-The `checkpoint_timeout` value can be increased from default value set on the server. Please note while increasing the `checkpoint_timeout` take into consideration that increasing the value would also increase the time for crash recovery.
+The `checkpoint_timeout` value can be increased from default value set on the server. Note while increasing the `checkpoint_timeout` take into consideration that increasing the value would also increase the time for crash recovery.
 
-#### Autovacuum tuning to decrease disruptions
+### Autovacuum tuning to decrease disruptions
 
-For more details on monitoring and tuning in scenarios where autovacuum is too disruptive please review [Autovacuum Tuning](./how-to-autovacuum-tuning.md).
+For more details on monitoring and tuning in scenarios where autovacuum is too disruptive review [Autovacuum Tuning](./how-to-autovacuum-tuning.md).
 
-####  Increase storage
+###  Increase storage
 
 Increasing storage will also help in addition of more IOPS to the server. For more details on storage and associated IOPS review [Compute and Storage Options](./concepts-compute-storage.md).
 
-### Next steps
+## Next steps
 
 - Troubleshoot and tune Autovacuum [Autovacuum Tuning](./how-to-autovacuum-tuning.md)
 - Compute and Storage Options [Compute and Storage Options](./concepts-compute-storage.md)