Merge pull request #180332 from GennadNY/gennadyk959

minor changes to network and params

Author: PRMerger8

articles/postgresql/flexible-server/concepts-networking.md

@@ -95,7 +95,7 @@ The custom DNS server should be inside the virtual network or reachable via the
 Private DNS zone settings and virtual network peering are independent of each other. If you want to connect to the flexible server from a client that's provisioned in another virtual network from the same region or a different region, you have to link the private DNS zone with the virtual network. For more information, see [Link the virtual network](../../dns/private-dns-getstarted-portal.md#link-the-virtual-network).
 
 > [!NOTE]
-> Only private DNS zone names that end with `postgres.database.azure.com` can be linked.
+> Only private DNS zone names that end with `postgres.database.azure.com` can be linked. Your DNS zone name cannot be the same as your flexible server(s) otherwise name resolution will fail. 
 
 ### Unsupported virtual network scenarios
 

articles/postgresql/flexible-server/concepts-server-parameters.md

@@ -35,7 +35,7 @@ Here is the list of some of the parameters:
 | **shared_buffers**    | The 'shared_buffers' setting changes depending on the selected SKU (SKU determines the memory available). General Purpose servers have 2GB shared_buffers for 2 vCores; Memory Optimized servers have 4GB shared_buffers for 2 vCores. The shared_buffers setting scales linearly (approximately) as vCores increase in a tier. | 
 | **shared_preload_libraries** | This parameter is available for configuration with a predefined set of supported extensions. Note that we always load the `azure` extension (used for maintenance tasks), as well as the `pg_stat_statements` extension (you can use the pg_stat_statements.track parameter to control whether the extension is active). |
 | **connection_throttling** | You can enable or disable temporary connection throttling per IP for too many invalid password login failures. |
- | **work_mem** | This parameter specifies the amount of memory to be used by internal sort operations and hash tables before writing to temporary disk files. If your workload has few queries with a lot of complex sorting and you have a lot of available memory, increasing this parameter may allow Postgres to do larger scans in-memory vs. spilling to disk, which will be faster.  Be careful however, as one complex query may have number of sort, hash operations running concurrently. Each one of those operations will use as much memory as it value allows before it starts writing to disk based temporary files. Therefore on a relatively busy system total memory usage will be many times of individual work_mem parameter. If you do decide to tune this value globally, you can use formula Total RAM * 0.25 / max_connections as initial value. Azure Database for PostgreSQL - Flexible Server supports range of 4096-2097151 bytes for this parameter.|
+ | **work_mem** | This parameter specifies the amount of memory to be used by internal sort operations and hash tables before writing to temporary disk files. If your workload has few queries with a lot of complex sorting and you have a lot of available memory, increasing this parameter may allow Postgres to do larger scans in-memory vs. spilling to disk, which will be faster.  Be careful however, as one complex query may have number of sort, hash operations running concurrently. Each one of those operations will use as much memory as it value allows before it starts writing to disk based temporary files. Therefore on a relatively busy system total memory usage will be many times of individual work_mem parameter. If you do decide to tune this value globally, you can use formula Total RAM * 0.25 / max_connections as initial value. Azure Database for PostgreSQL - Flexible Server supports range of 4096-2097152 kilobytes for this parameter.|
 | **effective_cache_size** |The effective_cache_size parameter estimates how much memory is available for disk caching by the operating system and within the database itself. The PostgreSQL query planner decides whether it’s fixed in RAM or not. Index scans are most likely to be used against higher values; otherwise, sequential scans will be used if the value is low. Recommendations are to set Effective_cache_size at 50% of the machine’s total RAM. |
 | **maintenance_work_mem** | The maintenance_work_mem parameter basically provides the maximum amount of memory to be used by maintenance operations like vacuum, create index, and alter table add foreign key operations.  Default value for that parameter is 64 KB. It’s recommended to set this value higher than work_mem; this can improve performance for vacuuming. |
 | **effective_io_concurrency** | Sets the number of concurrent disk I/O operations that PostgreSQL expects can be executed simultaneously. Raising this value will increase the number of I/O operations that any individual PostgreSQL session attempts to initiate in parallel. The allowed range is 1 to 1000, or zero to disable issuance of asynchronous I/O requests. Currently, this setting only affects bitmap heap scans.. |