chore: format content markdown files with Prettier

content/docs/connect/connection-pooling.md

@@ -70,7 +70,6 @@ Each Postgres connection creates a new process in the operating system, which co
 | 54                | 54   | 216 GB | 4000            |
 | 56                | 56   | 224 GB | 4000            |
 
-
 The formula used to calculate `max_connections` for Neon computes is `RAM in bytes / 9531392 bytes`. For a Neon Free Plan compute, which has 1 GB of RAM, this works out to approximately 112 connections. Larger computes offered with paid plans have more RAM and therefore support a larger number of connections. For example, a compute with 12 GB of RAM supports up to 1351 connections. You can check the `max_connections` limit for your compute by running the following query from the Neon SQL Editor or a client connected to Neon:
 
 ```sql

content/docs/extensions/pgvector.md

@@ -454,14 +454,13 @@ Like other index types, it’s faster to create an index after loading your init
 | 54                 | 54   | 216 GB | 3620 MB              |
 | 56                 | 56   | 224 GB | 3754 MB              |
 
+To optimize `pgvector` index build time, you can increase the `maintenance_work_mem` setting for the current session with a command similar to the following:
 
-  To optimize `pgvector` index build time, you can increase the `maintenance_work_mem` setting for the current session with a command similar to the following:
-
-  ```sql
-  SET maintenance_work_mem='10 GB';
-  ```
+```sql
+SET maintenance_work_mem='10 GB';
+```
 
-  The recommended setting is your working set size (the size of your tuples for vector index creation). However, your `maintenance_work_mem` setting should not exceed 50 to 60 percent of your compute's available RAM (see the table above). For example, the `maintenance_work_mem='10 GB'` setting shown above has been successfully tested on a 7 CU compute, which has 28 GB of RAM, as 10 GB is less than 50% of the RAM available for that compute size.
+The recommended setting is your working set size (the size of your tuples for vector index creation). However, your `maintenance_work_mem` setting should not exceed 50 to 60 percent of your compute's available RAM (see the table above). For example, the `maintenance_work_mem='10 GB'` setting shown above has been successfully tested on a 7 CU compute, which has 28 GB of RAM, as 10 GB is less than 50% of the RAM available for that compute size.
 
 - `max_parallel_maintenance_workers`
 

content/docs/guides/autoscaling-guide.md

@@ -35,7 +35,7 @@ To edit a compute:
 1. On the **Edit compute** settings drawer, toggle **Enable autoscaling** to enable it and use the slider to specify a minimum and maximum compute size.
    ![Autoscaling edit settings](/docs/introduction/autoscaling_config.png)
 
-   Neon scales the compute size up and down within the specified range to meet workload demand. Autoscaling currently supports a range of 1/4 (.25) to 16 vCPUs. One vCPU has 4 GB of RAM, 2 vCPUs have 8 GB of RAM, and so on. The amount of RAM in GB is always 4 times the number of vCPUs. For an overview of available compute sizes, see [Compute size and autoscaling configuration](/docs/manage/endpoints#compute-size-and-autoscaling-configuration). The maximum autoscaling setting cannot be more than 8 times the minimum setting when your maximum compute size is greater than 10. 
+   Neon scales the compute size up and down within the specified range to meet workload demand. Autoscaling currently supports a range of 1/4 (.25) to 16 vCPUs. One vCPU has 4 GB of RAM, 2 vCPUs have 8 GB of RAM, and so on. The amount of RAM in GB is always 4 times the number of vCPUs. For an overview of available compute sizes, see [Compute size and autoscaling configuration](/docs/manage/endpoints#compute-size-and-autoscaling-configuration). The maximum autoscaling setting cannot be more than 8 times the minimum setting when your maximum compute size is greater than 10.
 
    <Admonition type="note">
    You can configure the scale to zero setting for your compute at the same time. The scale to zero setting defines the period of inactivity after which a compute is automatically suspended. For more, see [Scale to Zero](/docs/introduction/scale-to-zero).

content/docs/introduction/usage-metrics.md

@@ -233,7 +233,6 @@ Compute hour usage is calculated by multiplying compute size by _active hours_.
 | 54            | 54   | 216 GB |
 | 56            | 56   | 224 GB |
 
-
 - A connection from a client or application activates a compute. Activity on the connection keeps the compute in an `Active` state. A defined period of inactivity (5 minutes by default) places the compute into an idle state.
 
 ### How Neon compute features affect usage