Merge pull request #4594 from EnterpriseDB/docs/edits-to-pr4554

edits to PR4554

product_docs/docs/epas/15/managing_performance/02_index_advisor/05_index_advisor_limitations.mdx

@@ -9,13 +9,13 @@ redirects:
 
 Prior to running the Index Advisor feature, review the following limitations:
 
-- Index Advisor doesn't consider Index Only scans. It does consider Index scans when making recommendations.
+- Index Advisor doesn't consider index-only scans. It does consider index scans when making recommendations.
 
 - Index Advisor ignores any computations found in the `WHERE` clause. Effectively, the index field in the recommendations isn't any kind of expression. The field is a simple column name.
 
 - Index Advisor doesn't consider inheritance when recommending hypothetical indexes. If a query references a parent table, Index Advisor doesn't make any index recommendations on child tables.
 
-- Suppose you're restoring a `pg_dump` backup file that includes the `index_advisor_log` table or any tables for which indexing recommendations were made and stored in the `index_advisor_log` table. Changes in object identifiers (OIDs) can result in "broken links" between the `index_advisor_log` table and the restored tables referenced by rows in the `index_advisor_log` table.
+- Suppose you're restoring a pg_dump backup file that includes the `index_advisor_log` table or any tables for which indexing recommendations were made and stored in the `index_advisor_log` table. Changes in object identifiers (OIDs) can result in broken links between the `index_advisor_log` table and the restored tables referenced by rows in the `index_advisor_log` table.
 
 - If you need to display the recommendations made prior to the backup, you can replace the old OIDs in the `reloid` column of the `index_advisor_log` table with the new OIDs of the referenced tables using the SQL `UPDATE` statement:
 

product_docs/docs/epas/15/managing_performance/03_sql_profiler.mdx

@@ -11,7 +11,7 @@ redirects:
 
 <div id="sql_profiler" class="registered_link"></div>
 
-Inefficient SQL code is a leading cause of database performance problems. The challenge for database administrators and developers is locating and then optimizing this code in large, complex systems. *SQL Profiler* helps you locate and optimize poorly running SQL code.
+Inefficient SQL code is a leading cause of database performance problems. The challenge for database administrators and developers is locating and then optimizing this code in large, complex systems. SQL Profiler helps you locate and optimize poorly running SQL code.
 
 Specific features and benefits of SQL Profiler include:
 

product_docs/docs/epas/15/managing_performance/using_dynatune.mdx

@@ -24,7 +24,7 @@ Here are some things to keep in mind when setting up dynamic tuning:
 
 - A low, non-zero value, that is, 1–33, dedicates the least amount of the host machine's resources to the database server. Use this setting for a development machine where many other applications are being used.
 
-- A value in the range of 34—66 dedicates a moderate amount of resources to the database server. You might use this setting for a dedicated application server that has a fixed number of other applications running on the same machine as EDB Postgres Advanced Server.
+- A value in the range of 34–66 dedicates a moderate amount of resources to the database server. You might use this setting for a dedicated application server that has a fixed number of other applications running on the same machine as EDB Postgres Advanced Server.
 
 - The highest values, that is, 67–100, dedicate most of the server's resources to the database server. Use this setting for a host machine that's totally dedicated to running EDB Postgres Advanced Server.