diff --git a/content/docs/connect/connection-pooling.md b/content/docs/connect/connection-pooling.md index b0cbb8295a..3c3a15e654 100644 --- a/content/docs/connect/connection-pooling.md +++ b/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 diff --git a/content/docs/extensions/pgvector.md b/content/docs/extensions/pgvector.md index 42c5fa43fb..220232c7d8 100644 --- a/content/docs/extensions/pgvector.md +++ b/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` diff --git a/content/docs/guides/autoscaling-guide.md b/content/docs/guides/autoscaling-guide.md index c5e3fa8a24..2d75c2a87d 100644 --- a/content/docs/guides/autoscaling-guide.md +++ b/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. 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). diff --git a/content/docs/introduction/usage-metrics.md b/content/docs/introduction/usage-metrics.md index 407c1a39cc..d9d18a771e 100644 --- a/content/docs/introduction/usage-metrics.md +++ b/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