资源使用情况/内存
autovacuum_work_mem
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置每个 autovacuum 工作进程要使用的最大内存。 |
| 数据类型 | integer |
| 默认值 | -1 |
| 允许的值 | -1-2097151 |
| 参数类型 | 动态 |
| 文档 | autovacuum_work_mem |
dynamic_shared_memory_type
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 选择使用的动态共享内存实现。 |
| 数据类型 | 枚举 |
| 默认值 | posix |
| 允许的值 | posix |
| 参数类型 | （只读） |
| 文档 | dynamic_shared_memory_type |
hash_mem_multiplier
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 要用于哈希表的多个 work_mem。 |
| 数据类型 | numeric |
| 默认值 | 2 |
| 允许的值 | 1-1000 |
| 参数类型 | 动态 |
| 文档 | hash_mem_multiplier |
huge_pages
| Attribute | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 允许/禁止使用大型内存页。 此设置不适用于少于 4 个 vCore 的服务器。 |
| 数据类型 | 枚举 |
| 默认值 | try |
| 允许的值 | on,off,try |
| 参数类型 | static |
| 文档 | huge_pages |
说明
通过大型页面功能，可以在较大的块中管理内存。 通常可管理最大 2 MB 的块，而不是标准的 4 KB 页面。
使用大型页面可提供有效分流 CPU 的性能优势：
- 它们减少了与内存管理任务相关的开销，例如更少的转换后备缓冲区 (TLB) 未命中。
- 它们缩短了内存管理所需的时间。
具体来说，在 PostgreSQL 中，只能将大型页面用于共享内存区域。 共享内存区域的很大一部分分配给了共享缓冲区。
另一个优点是，大型页面可阻止将共享内存区域交换到磁盘，这进一步稳定了性能。
建议
- 对于具有大量内存资源的服务器，请不要禁用大型页面。 禁用大型页面可能会损害性能。
- 如果一开始使用不支持大型页面的较小服务器，但预计会纵向扩展到支持大型页面的服务器，那么请将
huge_pages设置保留为TRY，以保证无缝转换和最佳性能。
特定于 Azure 的注释
对于具有 4 个或更多 vCore 的服务器，会从基础操作系统自动分配大型页面。 此功能不适用于少于 4 个 vCore 的服务器。 如果更改了任何共享内存设置，则会自动调整大型页面数量，包括更改 shared_buffers。
huge_page_size
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 应请求的大型页的大小。 |
| 数据类型 | integer |
| 默认值 | 0 |
| 允许的值 | 0 |
| 参数类型 | （只读） |
| 文档 | huge_page_size |
logical_decoding_work_mem
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置用于逻辑解码的最大内存。 |
| 数据类型 | integer |
| 默认值 | 65536 |
| 允许的值 | 64-2147483647 |
| 参数类型 | 动态 |
| 文档 | logical_decoding_work_mem |
maintenance_work_mem
| Attribute | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置用于维护操作（如 VACUUM、“创建索引”）的最大内存。 |
| 数据类型 | integer |
| 默认值 | 取决于分配给服务器的资源（vCore、RAM 或磁盘空间）。 |
| 允许的值 | 1024-2097151 |
| 参数类型 | 动态 |
| 文档 | maintenance_work_mem |
说明
maintenance_work_mem 是 PostgreSQL 中的一个配置参数。 它可控制为维护操作（例如 VACUUM、CREATE INDEX 和 ALTER TABLE）分配的内存量。 与影响查询操作内存分配的 work_mem 不同，maintenance_work_mem 是为维护和优化数据库结构的任务保留的。
要点
- Vacuum 内存上限：如果想要通过增加
maintenance_work_mem来更快地清理死元组，请注意，VACUUM对于收集死元组标识符有内置限制。 对于此过程，只能使用最多 1 GB 的内存。 - autovacuum 的内存分离：可以使用
autovacuum_work_mem设置单独控制 autovacuum 操作使用的内存。 此设置充当maintenance_work_mem的子集。 你可以决定在不影响其他维护任务和数据定义操作的内存分配的情况下 autovacuum 使用的内存量。
特定于 Azure 的注释
预配 Azure Database for PostgreSQL 灵活服务器的实例时，会根据为其计算选择的产品名称计算 maintenance_work_mem 参数的默认值。 如果对支持该灵活服务器的计算进行任何后续产品选择更改，该实例的 maintenance_work_mem 服务器参数的默认值不受任何影响。
每次更改分配给实例的产品时，还应根据以下公式中的值调整 maintenance_work_mem 参数的值。
用于计算 maintenance_work_mem 的值的公式是 (long)(82.5 * ln(memoryGiB) + 40) * 1024。
根据上一个公式，下表列出了此服务器参数将设置为的值，具体取决于预配的内存量：
| 内存大小 | maintenance_work_mem |
|---|---|
| 2 GiB | 99328 KiB |
| 4 GiB | 157696 KiB |
| 8 GiB | 216064 KiB |
| 16 GiB | 274432 KiB |
| 32 GiB | 332800 KiB |
| 48 GiB | 367616 KiB |
| 64 GiB | 392192 KiB |
| 80 GiB | 410624 KiB |
| 128 GiB | 450560 KiB |
| 160 GiB | 468992 KiB |
| 192 GiB | 484352 KiB |
| 256 GiB | 508928 KiB |
| 384 GiB | 542720 KiB |
| 432 GiB | 552960 KiB |
| 672 GiB | 590848 KiB |
max_prepared_transactions
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置同时准备的事务数量上限。 运行副本服务器时，必须将此参数设置为与主服务器上的值相同或更高的值。 |
| 数据类型 | integer |
| 默认值 | 0 |
| 允许的值 | 0-262143 |
| 参数类型 | static |
| 文档 | max_prepared_transactions |
max_stack_depth
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置最大堆栈深度（以 KB 为单位）。 |
| 数据类型 | integer |
| 默认值 | 2048 |
| 允许的值 | 2048 |
| 参数类型 | （只读） |
| 文档 | max_stack_depth |
min_dynamic_shared_memory
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 启动时保留的动态共享内存量。 |
| 数据类型 | integer |
| 默认值 | 0 |
| 允许的值 | 0 |
| 参数类型 | （只读） |
| 文档 | min_dynamic_shared_memory |
shared_buffers
| Attribute | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置服务器使用的共享内存缓冲区数。 单位为 8kb。 允许的值在 10% - 75% 的可用内存范围内。 |
| 数据类型 | integer |
| 默认值 | 取决于分配给服务器的资源（vCore、RAM 或磁盘空间）。 |
| 允许的值 | 16-1073741823 |
| 参数类型 | static |
| 文档 | shared_buffers |
说明
shared_buffers 配置参数确定分配给 PostgreSQL 数据库用于缓冲数据的系统内存量。 它是可供所有数据库进程访问的集中式内存池。
需要数据时，数据库进程首先检查共享缓冲区。 如果存在所需的数据，会快速检索此数据，并绕过更耗时的磁盘读取。 共享缓冲区在数据库进程和磁盘之间充当中介，并有效地减少所需的 I/O 操作数。
特定于 Azure 的注释
预配 Azure Database for PostgreSQL 灵活服务器的实例时，会根据为其计算选择的产品名称计算 shared_buffers 参数的默认值。 如果对支持该灵活服务器的计算进行任何后续产品选择更改，该实例的 shared_buffers 服务器参数的默认值不受任何影响。
每次更改分配给实例的产品时，还应根据以下公式中的值调整 shared_buffers 参数的值。
对于内存最多 2 GiB 的虚拟机，用于计算 shared_buffers 的值的公式是 memoryGib * 16384。
对于超过 2 GiB 的虚拟机，用于计算 shared_buffers 的值的公式是 memoryGib * 32768。
根据上一个公式，下表列出了此服务器参数将设置为的值，具体取决于预配的内存量：
| 内存大小 | shared_buffers |
|---|---|
| 2 GiB | 32768 |
| 4 GiB | 131072 |
| 8 GiB | 262144 |
| 16 GiB | 524288 |
| 32 GiB | 1048576 |
| 48 GiB | 1572864 |
| 64 GiB | 2097152 |
| 80 GiB | 2621440 |
| 128 GiB | 4194304 |
| 160 GiB | 5242880 |
| 192 GiB | 6291456 |
| 256 GiB | 8388608 |
| 384 GiB | 12582912 |
| 432 GiB | 14155776 |
| 672 GiB | 22020096 |
shared_memory_type
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 选择用于主共享内存区域的共享内存实现。 |
| 数据类型 | 枚举 |
| 默认值 | mmap |
| 允许的值 | mmap |
| 参数类型 | （只读） |
| 文档 | shared_memory_type |
temp_buffers
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置每个数据库会话使用的临时缓冲区数量上限。 |
| 数据类型 | integer |
| 默认值 | 1024 |
| 允许的值 | 100-1073741823 |
| 参数类型 | 动态 |
| 文档 | temp_buffers |
work_mem
| Attribute | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置写入到临时磁盘文件之前内部排序操作和哈希表要使用的内存量。 |
| 数据类型 | integer |
| 默认值 | 4096 |
| 允许的值 | 4096-2097151 |
| 参数类型 | 动态 |
| 文档 | work_mem |
说明
PostgreSQL 中的 work_mem 参数可控制在每个数据库会话的专用内存区域中为某些内部操作分配的内存量。 这些操作的示例包括排序和哈希处理。
与共享内存区域中的共享缓冲区不同，work_mem 是在每个会话或每个查询的专用内存空间中分配的。 通过设置足够的 work_mem 大小，可以显著提高这些操作的效率，并减少将临时数据写入磁盘的需求。
要点
- 专用连接内存：
work_mem是每个数据库会话使用的专用内存的一部分。 此内存不同于shared_buffers使用的共享内存区域。 - 特定于查询的用法：并非所有会话或查询都使用
work_mem。 简单的查询（例如SELECT 1）不太可能需要work_mem。 但是，涉及排序或哈希处理等操作的复杂查询可能使用work_mem的一个或多个区块。 - 并行操作：对于跨多个并行后端的查询，每个后端可能会使用
work_mem的一个或多个区块。
监视和调整 work_mem
必须持续监视系统性能，并根据需要调整 work_mem，主要是在与排序或哈希处理操作相关的查询执行时间缓慢时。 下面是使用 Azure 门户中提供的工具监视性能的方法：
- 查询性能见解：查看“按临时文件数排名靠前的查询”选项卡，以确定生成临时文件的查询。 这种情况表明，可能需要增加
work_mem。 - 故障排除指南：使用故障排除指南中的“大量临时文件”选项卡来确定有问题的查询。
精细调整
在管理 work_mem 参数时，采用精细调整方法通常比设置全局值更高效。 此方法可确保根据进程和用户的特定需求明智地分配内存。 它还将遇到内存不足问题的风险降到最低。 下面是实现这一点的步骤：
用户级别：如果特定用户主要涉及聚合或报告任务（内存密集型任务），请考虑自定义该用户的
work_mem值。 使用ALTER ROLE命令提高用户操作的性能。函数/过程级别：如果特定函数或过程生成大量临时文件，那么增加特定函数或过程级别的
work_mem值可能会有所帮助。 使用ALTER FUNCTION或ALTER PROCEDURE命令专门为这些操作分配更多内存。数据库级别：如果只有特定数据库生成大量临时文件，请在数据库级别更改
work_mem。全局级别：如果系统分析显示大多数查询生成小型临时文件，而只有少数查询创建大型临时文件，那么最好全局调高
work_mem值。 此操作可促使在内存中处理大多数查询，这样就可避免基于磁盘的操作并提高效率。 但是，请始终谨慎操作并监视服务器上的内存利用率，确保它可处理增加的work_mem值。
确定排序操作的最小 work_mem 值
若要查找特定查询的最小 work_mem 值，尤其是在排序过程中生成临时磁盘文件的查询，请先考虑在查询执行期间生成的临时文件大小。 例如，如果一个查询生成一个 20 MB 的临时文件：
- 使用 psql 或偏好的 PostgreSQL 客户端连接到数据库。
- 设置略高于 20 MB 的初始
work_mem值，以便在内存中处理时考虑到额外的标头。 使用SET work_mem TO '25MB'等命令。 - 在同一会话上对有问题的查询运行
EXPLAIN ANALYZE。 - 查看
"Sort Method: quicksort Memory: xkB"的输出。 如果指示"external merge Disk: xkB"，请以增量方式增加work_mem值并重新测试，直到出现"quicksort Memory"。 出现"quicksort Memory"即表示查询现在内存中运行。 - 通过此方法确定值后，可以全局应用该值，也可在更精细的级别应用它（如上所述）来满足你的操作需求。
autovacuum_work_mem
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置每个 autovacuum 工作进程要使用的最大内存。 |
| 数据类型 | integer |
| 默认值 | -1 |
| 允许的值 | -1-2097151 |
| 参数类型 | 动态 |
| 文档 | autovacuum_work_mem |
dynamic_shared_memory_type
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 选择使用的动态共享内存实现。 |
| 数据类型 | 枚举 |
| 默认值 | posix |
| 允许的值 | posix |
| 参数类型 | （只读） |
| 文档 | dynamic_shared_memory_type |
hash_mem_multiplier
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 要用于哈希表的多个 work_mem。 |
| 数据类型 | numeric |
| 默认值 | 2 |
| 允许的值 | 1-1000 |
| 参数类型 | 动态 |
| 文档 | hash_mem_multiplier |
huge_pages
| Attribute | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 允许/禁止使用大型内存页。 此设置不适用于少于 4 个 vCore 的服务器。 |
| 数据类型 | 枚举 |
| 默认值 | try |
| 允许的值 | on,off,try |
| 参数类型 | static |
| 文档 | huge_pages |
说明
通过大型页面功能，可以在较大的块中管理内存。 通常可管理最大 2 MB 的块，而不是标准的 4 KB 页面。
使用大型页面可提供有效分流 CPU 的性能优势：
- 它们减少了与内存管理任务相关的开销，例如更少的转换后备缓冲区 (TLB) 未命中。
- 它们缩短了内存管理所需的时间。
具体来说，在 PostgreSQL 中，只能将大型页面用于共享内存区域。 共享内存区域的很大一部分分配给了共享缓冲区。
另一个优点是，大型页面可阻止将共享内存区域交换到磁盘，这进一步稳定了性能。
建议
- 对于具有大量内存资源的服务器，请不要禁用大型页面。 禁用大型页面可能会损害性能。
- 如果一开始使用不支持大型页面的较小服务器，但预计会纵向扩展到支持大型页面的服务器，那么请将
huge_pages设置保留为TRY，以保证无缝转换和最佳性能。
特定于 Azure 的注释
对于具有 4 个或更多 vCore 的服务器，会从基础操作系统自动分配大型页面。 此功能不适用于少于 4 个 vCore 的服务器。 如果更改了任何共享内存设置，则会自动调整大型页面数量，包括更改 shared_buffers。
huge_page_size
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 应请求的大型页的大小。 |
| 数据类型 | integer |
| 默认值 | 0 |
| 允许的值 | 0 |
| 参数类型 | （只读） |
| 文档 | huge_page_size |
logical_decoding_work_mem
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置用于逻辑解码的最大内存。 |
| 数据类型 | integer |
| 默认值 | 65536 |
| 允许的值 | 64-2147483647 |
| 参数类型 | 动态 |
| 文档 | logical_decoding_work_mem |
maintenance_work_mem
| Attribute | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置用于维护操作（如 VACUUM、“创建索引”）的最大内存。 |
| 数据类型 | integer |
| 默认值 | 取决于分配给服务器的资源（vCore、RAM 或磁盘空间）。 |
| 允许的值 | 1024-2097151 |
| 参数类型 | 动态 |
| 文档 | maintenance_work_mem |
说明
maintenance_work_mem 是 PostgreSQL 中的一个配置参数。 它可控制为维护操作（例如 VACUUM、CREATE INDEX 和 ALTER TABLE）分配的内存量。 与影响查询操作内存分配的 work_mem 不同，maintenance_work_mem 是为维护和优化数据库结构的任务保留的。
要点
- Vacuum 内存上限：如果想要通过增加
maintenance_work_mem来更快地清理死元组，请注意，VACUUM对于收集死元组标识符有内置限制。 对于此过程，只能使用最多 1 GB 的内存。 - autovacuum 的内存分离：可以使用
autovacuum_work_mem设置单独控制 autovacuum 操作使用的内存。 此设置充当maintenance_work_mem的子集。 你可以决定在不影响其他维护任务和数据定义操作的内存分配的情况下 autovacuum 使用的内存量。
特定于 Azure 的注释
预配 Azure Database for PostgreSQL 灵活服务器的实例时，会根据为其计算选择的产品名称计算 maintenance_work_mem 参数的默认值。 如果对支持该灵活服务器的计算进行任何后续产品选择更改，该实例的 maintenance_work_mem 服务器参数的默认值不受任何影响。
每次更改分配给实例的产品时，还应根据以下公式中的值调整 maintenance_work_mem 参数的值。
用于计算 maintenance_work_mem 的值的公式是 (long)(82.5 * ln(memoryGiB) + 40) * 1024。
根据上一个公式，下表列出了此服务器参数将设置为的值，具体取决于预配的内存量：
| 内存大小 | maintenance_work_mem |
|---|---|
| 2 GiB | 99328 KiB |
| 4 GiB | 157696 KiB |
| 8 GiB | 216064 KiB |
| 16 GiB | 274432 KiB |
| 32 GiB | 332800 KiB |
| 48 GiB | 367616 KiB |
| 64 GiB | 392192 KiB |
| 80 GiB | 410624 KiB |
| 128 GiB | 450560 KiB |
| 160 GiB | 468992 KiB |
| 192 GiB | 484352 KiB |
| 256 GiB | 508928 KiB |
| 384 GiB | 542720 KiB |
| 432 GiB | 552960 KiB |
| 672 GiB | 590848 KiB |
max_prepared_transactions
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置同时准备的事务数量上限。 运行副本服务器时，必须将此参数设置为与主服务器上的值相同或更高的值。 |
| 数据类型 | integer |
| 默认值 | 0 |
| 允许的值 | 0-262143 |
| 参数类型 | static |
| 文档 | max_prepared_transactions |
max_stack_depth
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置最大堆栈深度（以 KB 为单位）。 |
| 数据类型 | integer |
| 默认值 | 2048 |
| 允许的值 | 2048 |
| 参数类型 | （只读） |
| 文档 | max_stack_depth |
min_dynamic_shared_memory
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 启动时保留的动态共享内存量。 |
| 数据类型 | integer |
| 默认值 | 0 |
| 允许的值 | 0 |
| 参数类型 | （只读） |
| 文档 | min_dynamic_shared_memory |
shared_buffers
| Attribute | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置服务器使用的共享内存缓冲区数。 单位为 8kb。 允许的值在 10% - 75% 的可用内存范围内。 |
| 数据类型 | integer |
| 默认值 | 取决于分配给服务器的资源（vCore、RAM 或磁盘空间）。 |
| 允许的值 | 16-1073741823 |
| 参数类型 | static |
| 文档 | shared_buffers |
说明
shared_buffers 配置参数确定分配给 PostgreSQL 数据库用于缓冲数据的系统内存量。 它是可供所有数据库进程访问的集中式内存池。
需要数据时，数据库进程首先检查共享缓冲区。 如果存在所需的数据，会快速检索此数据，并绕过更耗时的磁盘读取。 共享缓冲区在数据库进程和磁盘之间充当中介，并有效地减少所需的 I/O 操作数。
特定于 Azure 的注释
预配 Azure Database for PostgreSQL 灵活服务器的实例时，会根据为其计算选择的产品名称计算 shared_buffers 参数的默认值。 如果对支持该灵活服务器的计算进行任何后续产品选择更改，该实例的 shared_buffers 服务器参数的默认值不受任何影响。
每次更改分配给实例的产品时，还应根据以下公式中的值调整 shared_buffers 参数的值。
对于内存最多 2 GiB 的虚拟机，用于计算 shared_buffers 的值的公式是 memoryGib * 16384。
对于超过 2 GiB 的虚拟机，用于计算 shared_buffers 的值的公式是 memoryGib * 32768。
根据上一个公式，下表列出了此服务器参数将设置为的值，具体取决于预配的内存量：
| 内存大小 | shared_buffers |
|---|---|
| 2 GiB | 32768 |
| 4 GiB | 131072 |
| 8 GiB | 262144 |
| 16 GiB | 524288 |
| 32 GiB | 1048576 |
| 48 GiB | 1572864 |
| 64 GiB | 2097152 |
| 80 GiB | 2621440 |
| 128 GiB | 4194304 |
| 160 GiB | 5242880 |
| 192 GiB | 6291456 |
| 256 GiB | 8388608 |
| 384 GiB | 12582912 |
| 432 GiB | 14155776 |
| 672 GiB | 22020096 |
shared_memory_type
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 选择用于主共享内存区域的共享内存实现。 |
| 数据类型 | 枚举 |
| 默认值 | mmap |
| 允许的值 | mmap |
| 参数类型 | （只读） |
| 文档 | shared_memory_type |
temp_buffers
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置每个数据库会话使用的临时缓冲区数量上限。 |
| 数据类型 | integer |
| 默认值 | 1024 |
| 允许的值 | 100-1073741823 |
| 参数类型 | 动态 |
| 文档 | temp_buffers |
work_mem
| Attribute | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置写入到临时磁盘文件之前内部排序操作和哈希表要使用的内存量。 |
| 数据类型 | integer |
| 默认值 | 4096 |
| 允许的值 | 4096-2097151 |
| 参数类型 | 动态 |
| 文档 | work_mem |
说明
PostgreSQL 中的 work_mem 参数可控制在每个数据库会话的专用内存区域中为某些内部操作分配的内存量。 这些操作的示例包括排序和哈希处理。
与共享内存区域中的共享缓冲区不同，work_mem 是在每个会话或每个查询的专用内存空间中分配的。 通过设置足够的 work_mem 大小，可以显著提高这些操作的效率，并减少将临时数据写入磁盘的需求。
要点
- 专用连接内存：
work_mem是每个数据库会话使用的专用内存的一部分。 此内存不同于shared_buffers使用的共享内存区域。 - 特定于查询的用法：并非所有会话或查询都使用
work_mem。 简单的查询（例如SELECT 1）不太可能需要work_mem。 但是，涉及排序或哈希处理等操作的复杂查询可能使用work_mem的一个或多个区块。 - 并行操作：对于跨多个并行后端的查询，每个后端可能会使用
work_mem的一个或多个区块。
监视和调整 work_mem
必须持续监视系统性能，并根据需要调整 work_mem，主要是在与排序或哈希处理操作相关的查询执行时间缓慢时。 下面是使用 Azure 门户中提供的工具监视性能的方法：
- 查询性能见解：查看“按临时文件数排名靠前的查询”选项卡，以确定生成临时文件的查询。 这种情况表明，可能需要增加
work_mem。 - 故障排除指南：使用故障排除指南中的“大量临时文件”选项卡来确定有问题的查询。
精细调整
在管理 work_mem 参数时，采用精细调整方法通常比设置全局值更高效。 此方法可确保根据进程和用户的特定需求明智地分配内存。 它还将遇到内存不足问题的风险降到最低。 下面是实现这一点的步骤：
用户级别：如果特定用户主要涉及聚合或报告任务（内存密集型任务），请考虑自定义该用户的
work_mem值。 使用ALTER ROLE命令提高用户操作的性能。函数/过程级别：如果特定函数或过程生成大量临时文件，那么增加特定函数或过程级别的
work_mem值可能会有所帮助。 使用ALTER FUNCTION或ALTER PROCEDURE命令专门为这些操作分配更多内存。数据库级别：如果只有特定数据库生成大量临时文件，请在数据库级别更改
work_mem。全局级别：如果系统分析显示大多数查询生成小型临时文件，而只有少数查询创建大型临时文件，那么最好全局调高
work_mem值。 此操作可促使在内存中处理大多数查询，这样就可避免基于磁盘的操作并提高效率。 但是，请始终谨慎操作并监视服务器上的内存利用率，确保它可处理增加的work_mem值。
确定排序操作的最小 work_mem 值
若要查找特定查询的最小 work_mem 值，尤其是在排序过程中生成临时磁盘文件的查询，请先考虑在查询执行期间生成的临时文件大小。 例如，如果一个查询生成一个 20 MB 的临时文件：
- 使用 psql 或偏好的 PostgreSQL 客户端连接到数据库。
- 设置略高于 20 MB 的初始
work_mem值，以便在内存中处理时考虑到额外的标头。 使用SET work_mem TO '25MB'等命令。 - 在同一会话上对有问题的查询运行
EXPLAIN ANALYZE。 - 查看
"Sort Method: quicksort Memory: xkB"的输出。 如果指示"external merge Disk: xkB"，请以增量方式增加work_mem值并重新测试，直到出现"quicksort Memory"。 出现"quicksort Memory"即表示查询现在内存中运行。 - 通过此方法确定值后，可以全局应用该值，也可在更精细的级别应用它（如上所述）来满足你的操作需求。
autovacuum_work_mem
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置每个 autovacuum 工作进程要使用的最大内存。 |
| 数据类型 | integer |
| 默认值 | -1 |
| 允许的值 | -1-2097151 |
| 参数类型 | 动态 |
| 文档 | autovacuum_work_mem |
dynamic_shared_memory_type
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 选择使用的动态共享内存实现。 |
| 数据类型 | 枚举 |
| 默认值 | posix |
| 允许的值 | posix |
| 参数类型 | （只读） |
| 文档 | dynamic_shared_memory_type |
hash_mem_multiplier
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 要用于哈希表的多个 work_mem。 |
| 数据类型 | numeric |
| 默认值 | 1 |
| 允许的值 | 1-1000 |
| 参数类型 | 动态 |
| 文档 | hash_mem_multiplier |
huge_pages
| Attribute | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 允许/禁止使用大型内存页。 此设置不适用于少于 4 个 vCore 的服务器。 |
| 数据类型 | 枚举 |
| 默认值 | try |
| 允许的值 | on,off,try |
| 参数类型 | static |
| 文档 | huge_pages |
说明
通过大型页面功能，可以在较大的块中管理内存。 通常可管理最大 2 MB 的块，而不是标准的 4 KB 页面。
使用大型页面可提供有效分流 CPU 的性能优势：
- 它们减少了与内存管理任务相关的开销，例如更少的转换后备缓冲区 (TLB) 未命中。
- 它们缩短了内存管理所需的时间。
具体来说，在 PostgreSQL 中，只能将大型页面用于共享内存区域。 共享内存区域的很大一部分分配给了共享缓冲区。
另一个优点是，大型页面可阻止将共享内存区域交换到磁盘，这进一步稳定了性能。
建议
- 对于具有大量内存资源的服务器，请不要禁用大型页面。 禁用大型页面可能会损害性能。
- 如果一开始使用不支持大型页面的较小服务器，但预计会纵向扩展到支持大型页面的服务器，那么请将
huge_pages设置保留为TRY，以保证无缝转换和最佳性能。
特定于 Azure 的注释
对于具有 4 个或更多 vCore 的服务器，会从基础操作系统自动分配大型页面。 此功能不适用于少于 4 个 vCore 的服务器。 如果更改了任何共享内存设置，则会自动调整大型页面数量，包括更改 shared_buffers。
huge_page_size
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 应请求的大型页的大小。 |
| 数据类型 | integer |
| 默认值 | 0 |
| 允许的值 | 0 |
| 参数类型 | （只读） |
| 文档 | huge_page_size |
logical_decoding_work_mem
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置用于逻辑解码的最大内存。 |
| 数据类型 | integer |
| 默认值 | 65536 |
| 允许的值 | 64-2147483647 |
| 参数类型 | 动态 |
| 文档 | logical_decoding_work_mem |
maintenance_work_mem
| Attribute | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置用于维护操作（如 VACUUM、“创建索引”）的最大内存。 |
| 数据类型 | integer |
| 默认值 | 取决于分配给服务器的资源（vCore、RAM 或磁盘空间）。 |
| 允许的值 | 1024-2097151 |
| 参数类型 | 动态 |
| 文档 | maintenance_work_mem |
说明
maintenance_work_mem 是 PostgreSQL 中的一个配置参数。 它可控制为维护操作（例如 VACUUM、CREATE INDEX 和 ALTER TABLE）分配的内存量。 与影响查询操作内存分配的 work_mem 不同，maintenance_work_mem 是为维护和优化数据库结构的任务保留的。
要点
- Vacuum 内存上限：如果想要通过增加
maintenance_work_mem来更快地清理死元组，请注意，VACUUM对于收集死元组标识符有内置限制。 对于此过程，只能使用最多 1 GB 的内存。 - autovacuum 的内存分离：可以使用
autovacuum_work_mem设置单独控制 autovacuum 操作使用的内存。 此设置充当maintenance_work_mem的子集。 你可以决定在不影响其他维护任务和数据定义操作的内存分配的情况下 autovacuum 使用的内存量。
特定于 Azure 的注释
预配 Azure Database for PostgreSQL 灵活服务器的实例时，会根据为其计算选择的产品名称计算 maintenance_work_mem 参数的默认值。 如果对支持该灵活服务器的计算进行任何后续产品选择更改，该实例的 maintenance_work_mem 服务器参数的默认值不受任何影响。
每次更改分配给实例的产品时，还应根据以下公式中的值调整 maintenance_work_mem 参数的值。
用于计算 maintenance_work_mem 的值的公式是 (long)(82.5 * ln(memoryGiB) + 40) * 1024。
根据上一个公式，下表列出了此服务器参数将设置为的值，具体取决于预配的内存量：
| 内存大小 | maintenance_work_mem |
|---|---|
| 2 GiB | 99328 KiB |
| 4 GiB | 157696 KiB |
| 8 GiB | 216064 KiB |
| 16 GiB | 274432 KiB |
| 32 GiB | 332800 KiB |
| 48 GiB | 367616 KiB |
| 64 GiB | 392192 KiB |
| 80 GiB | 410624 KiB |
| 128 GiB | 450560 KiB |
| 160 GiB | 468992 KiB |
| 192 GiB | 484352 KiB |
| 256 GiB | 508928 KiB |
| 384 GiB | 542720 KiB |
| 432 GiB | 552960 KiB |
| 672 GiB | 590848 KiB |
max_prepared_transactions
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置同时准备的事务数量上限。 运行副本服务器时，必须将此参数设置为与主服务器上的值相同或更高的值。 |
| 数据类型 | integer |
| 默认值 | 0 |
| 允许的值 | 0-262143 |
| 参数类型 | static |
| 文档 | max_prepared_transactions |
max_stack_depth
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置最大堆栈深度（以 KB 为单位）。 |
| 数据类型 | integer |
| 默认值 | 2048 |
| 允许的值 | 2048 |
| 参数类型 | （只读） |
| 文档 | max_stack_depth |
min_dynamic_shared_memory
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 启动时保留的动态共享内存量。 |
| 数据类型 | integer |
| 默认值 | 0 |
| 允许的值 | 0 |
| 参数类型 | （只读） |
| 文档 | min_dynamic_shared_memory |
shared_buffers
| Attribute | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置服务器使用的共享内存缓冲区数。 单位为 8kb。 允许的值在 10% - 75% 的可用内存范围内。 |
| 数据类型 | integer |
| 默认值 | 取决于分配给服务器的资源（vCore、RAM 或磁盘空间）。 |
| 允许的值 | 16-1073741823 |
| 参数类型 | static |
| 文档 | shared_buffers |
说明
shared_buffers 配置参数确定分配给 PostgreSQL 数据库用于缓冲数据的系统内存量。 它是可供所有数据库进程访问的集中式内存池。
需要数据时，数据库进程首先检查共享缓冲区。 如果存在所需的数据，会快速检索此数据，并绕过更耗时的磁盘读取。 共享缓冲区在数据库进程和磁盘之间充当中介，并有效地减少所需的 I/O 操作数。
特定于 Azure 的注释
预配 Azure Database for PostgreSQL 灵活服务器的实例时，会根据为其计算选择的产品名称计算 shared_buffers 参数的默认值。 如果对支持该灵活服务器的计算进行任何后续产品选择更改，该实例的 shared_buffers 服务器参数的默认值不受任何影响。
每次更改分配给实例的产品时，还应根据以下公式中的值调整 shared_buffers 参数的值。
对于内存最多 2 GiB 的虚拟机，用于计算 shared_buffers 的值的公式是 memoryGib * 16384。
对于超过 2 GiB 的虚拟机，用于计算 shared_buffers 的值的公式是 memoryGib * 32768。
根据上一个公式，下表列出了此服务器参数将设置为的值，具体取决于预配的内存量：
| 内存大小 | shared_buffers |
|---|---|
| 2 GiB | 32768 |
| 4 GiB | 131072 |
| 8 GiB | 262144 |
| 16 GiB | 524288 |
| 32 GiB | 1048576 |
| 48 GiB | 1572864 |
| 64 GiB | 2097152 |
| 80 GiB | 2621440 |
| 128 GiB | 4194304 |
| 160 GiB | 5242880 |
| 192 GiB | 6291456 |
| 256 GiB | 8388608 |
| 384 GiB | 12582912 |
| 432 GiB | 14155776 |
| 672 GiB | 22020096 |
shared_memory_type
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 选择用于主共享内存区域的共享内存实现。 |
| 数据类型 | 枚举 |
| 默认值 | mmap |
| 允许的值 | mmap |
| 参数类型 | （只读） |
| 文档 | shared_memory_type |
temp_buffers
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置每个数据库会话使用的临时缓冲区数量上限。 |
| 数据类型 | integer |
| 默认值 | 1024 |
| 允许的值 | 100-1073741823 |
| 参数类型 | 动态 |
| 文档 | temp_buffers |
work_mem
| Attribute | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置写入到临时磁盘文件之前内部排序操作和哈希表要使用的内存量。 |
| 数据类型 | integer |
| 默认值 | 4096 |
| 允许的值 | 4096-2097151 |
| 参数类型 | 动态 |
| 文档 | work_mem |
说明
PostgreSQL 中的 work_mem 参数可控制在每个数据库会话的专用内存区域中为某些内部操作分配的内存量。 这些操作的示例包括排序和哈希处理。
与共享内存区域中的共享缓冲区不同，work_mem 是在每个会话或每个查询的专用内存空间中分配的。 通过设置足够的 work_mem 大小，可以显著提高这些操作的效率，并减少将临时数据写入磁盘的需求。
要点
- 专用连接内存：
work_mem是每个数据库会话使用的专用内存的一部分。 此内存不同于shared_buffers使用的共享内存区域。 - 特定于查询的用法：并非所有会话或查询都使用
work_mem。 简单的查询（例如SELECT 1）不太可能需要work_mem。 但是，涉及排序或哈希处理等操作的复杂查询可能使用work_mem的一个或多个区块。 - 并行操作：对于跨多个并行后端的查询，每个后端可能会使用
work_mem的一个或多个区块。
监视和调整 work_mem
必须持续监视系统性能，并根据需要调整 work_mem，主要是在与排序或哈希处理操作相关的查询执行时间缓慢时。 下面是使用 Azure 门户中提供的工具监视性能的方法：
- 查询性能见解：查看“按临时文件数排名靠前的查询”选项卡，以确定生成临时文件的查询。 这种情况表明，可能需要增加
work_mem。 - 故障排除指南：使用故障排除指南中的“大量临时文件”选项卡来确定有问题的查询。
精细调整
在管理 work_mem 参数时，采用精细调整方法通常比设置全局值更高效。 此方法可确保根据进程和用户的特定需求明智地分配内存。 它还将遇到内存不足问题的风险降到最低。 下面是实现这一点的步骤：
用户级别：如果特定用户主要涉及聚合或报告任务（内存密集型任务），请考虑自定义该用户的
work_mem值。 使用ALTER ROLE命令提高用户操作的性能。函数/过程级别：如果特定函数或过程生成大量临时文件，那么增加特定函数或过程级别的
work_mem值可能会有所帮助。 使用ALTER FUNCTION或ALTER PROCEDURE命令专门为这些操作分配更多内存。数据库级别：如果只有特定数据库生成大量临时文件，请在数据库级别更改
work_mem。全局级别：如果系统分析显示大多数查询生成小型临时文件，而只有少数查询创建大型临时文件，那么最好全局调高
work_mem值。 此操作可促使在内存中处理大多数查询，这样就可避免基于磁盘的操作并提高效率。 但是，请始终谨慎操作并监视服务器上的内存利用率，确保它可处理增加的work_mem值。
确定排序操作的最小 work_mem 值
若要查找特定查询的最小 work_mem 值，尤其是在排序过程中生成临时磁盘文件的查询，请先考虑在查询执行期间生成的临时文件大小。 例如，如果一个查询生成一个 20 MB 的临时文件：
- 使用 psql 或偏好的 PostgreSQL 客户端连接到数据库。
- 设置略高于 20 MB 的初始
work_mem值，以便在内存中处理时考虑到额外的标头。 使用SET work_mem TO '25MB'等命令。 - 在同一会话上对有问题的查询运行
EXPLAIN ANALYZE。 - 查看
"Sort Method: quicksort Memory: xkB"的输出。 如果指示"external merge Disk: xkB"，请以增量方式增加work_mem值并重新测试，直到出现"quicksort Memory"。 出现"quicksort Memory"即表示查询现在内存中运行。 - 通过此方法确定值后，可以全局应用该值，也可在更精细的级别应用它（如上所述）来满足你的操作需求。
autovacuum_work_mem
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置每个 autovacuum 工作进程要使用的最大内存。 |
| 数据类型 | integer |
| 默认值 | -1 |
| 允许的值 | -1-2097151 |
| 参数类型 | 动态 |
| 文档 | autovacuum_work_mem |
dynamic_shared_memory_type
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 选择使用的动态共享内存实现。 |
| 数据类型 | 枚举 |
| 默认值 | posix |
| 允许的值 | posix |
| 参数类型 | （只读） |
| 文档 | dynamic_shared_memory_type |
hash_mem_multiplier
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 要用于哈希表的多个 work_mem。 |
| 数据类型 | numeric |
| 默认值 | 1 |
| 允许的值 | 1-1000 |
| 参数类型 | 动态 |
| 文档 | hash_mem_multiplier |
huge_pages
| Attribute | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 允许/禁止使用大型内存页。 此设置不适用于少于 4 个 vCore 的服务器。 |
| 数据类型 | 枚举 |
| 默认值 | try |
| 允许的值 | on,off,try |
| 参数类型 | static |
| 文档 | huge_pages |
说明
通过大型页面功能，可以在较大的块中管理内存。 通常可管理最大 2 MB 的块，而不是标准的 4 KB 页面。
使用大型页面可提供有效分流 CPU 的性能优势：
- 它们减少了与内存管理任务相关的开销，例如更少的转换后备缓冲区 (TLB) 未命中。
- 它们缩短了内存管理所需的时间。
具体来说，在 PostgreSQL 中，只能将大型页面用于共享内存区域。 共享内存区域的很大一部分分配给了共享缓冲区。
另一个优点是，大型页面可阻止将共享内存区域交换到磁盘，这进一步稳定了性能。
建议
- 对于具有大量内存资源的服务器，请不要禁用大型页面。 禁用大型页面可能会损害性能。
- 如果一开始使用不支持大型页面的较小服务器，但预计会纵向扩展到支持大型页面的服务器，那么请将
huge_pages设置保留为TRY，以保证无缝转换和最佳性能。
特定于 Azure 的注释
对于具有 4 个或更多 vCore 的服务器，会从基础操作系统自动分配大型页面。 此功能不适用于少于 4 个 vCore 的服务器。 如果更改了任何共享内存设置，则会自动调整大型页面数量，包括更改 shared_buffers。
logical_decoding_work_mem
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置用于逻辑解码的最大内存。 |
| 数据类型 | integer |
| 默认值 | 65536 |
| 允许的值 | 64-2147483647 |
| 参数类型 | 动态 |
| 文档 | logical_decoding_work_mem |
maintenance_work_mem
| Attribute | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置用于维护操作（如 VACUUM、“创建索引”）的最大内存。 |
| 数据类型 | integer |
| 默认值 | 取决于分配给服务器的资源（vCore、RAM 或磁盘空间）。 |
| 允许的值 | 1024-2097151 |
| 参数类型 | 动态 |
| 文档 | maintenance_work_mem |
说明
maintenance_work_mem 是 PostgreSQL 中的一个配置参数。 它可控制为维护操作（例如 VACUUM、CREATE INDEX 和 ALTER TABLE）分配的内存量。 与影响查询操作内存分配的 work_mem 不同，maintenance_work_mem 是为维护和优化数据库结构的任务保留的。
要点
- Vacuum 内存上限：如果想要通过增加
maintenance_work_mem来更快地清理死元组，请注意，VACUUM对于收集死元组标识符有内置限制。 对于此过程，只能使用最多 1 GB 的内存。 - autovacuum 的内存分离：可以使用
autovacuum_work_mem设置单独控制 autovacuum 操作使用的内存。 此设置充当maintenance_work_mem的子集。 你可以决定在不影响其他维护任务和数据定义操作的内存分配的情况下 autovacuum 使用的内存量。
特定于 Azure 的注释
预配 Azure Database for PostgreSQL 灵活服务器的实例时，会根据为其计算选择的产品名称计算 maintenance_work_mem 参数的默认值。 如果对支持该灵活服务器的计算进行任何后续产品选择更改，该实例的 maintenance_work_mem 服务器参数的默认值不受任何影响。
每次更改分配给实例的产品时，还应根据以下公式中的值调整 maintenance_work_mem 参数的值。
用于计算 maintenance_work_mem 的值的公式是 (long)(82.5 * ln(memoryGiB) + 40) * 1024。
根据上一个公式，下表列出了此服务器参数将设置为的值，具体取决于预配的内存量：
| 内存大小 | maintenance_work_mem |
|---|---|
| 2 GiB | 99328 KiB |
| 4 GiB | 157696 KiB |
| 8 GiB | 216064 KiB |
| 16 GiB | 274432 KiB |
| 32 GiB | 332800 KiB |
| 48 GiB | 367616 KiB |
| 64 GiB | 392192 KiB |
| 80 GiB | 410624 KiB |
| 128 GiB | 450560 KiB |
| 160 GiB | 468992 KiB |
| 192 GiB | 484352 KiB |
| 256 GiB | 508928 KiB |
| 384 GiB | 542720 KiB |
| 432 GiB | 552960 KiB |
| 672 GiB | 590848 KiB |
max_prepared_transactions
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置同时准备的事务数量上限。 运行副本服务器时，必须将此参数设置为与主服务器上的值相同或更高的值。 |
| 数据类型 | integer |
| 默认值 | 0 |
| 允许的值 | 0-262143 |
| 参数类型 | static |
| 文档 | max_prepared_transactions |
max_stack_depth
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置最大堆栈深度（以 KB 为单位）。 |
| 数据类型 | integer |
| 默认值 | 2048 |
| 允许的值 | 2048 |
| 参数类型 | （只读） |
| 文档 | max_stack_depth |
shared_buffers
| Attribute | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置服务器使用的共享内存缓冲区数。 单位为 8kb。 允许的值在 10% - 75% 的可用内存范围内。 |
| 数据类型 | integer |
| 默认值 | 取决于分配给服务器的资源（vCore、RAM 或磁盘空间）。 |
| 允许的值 | 16-1073741823 |
| 参数类型 | static |
| 文档 | shared_buffers |
说明
shared_buffers 配置参数确定分配给 PostgreSQL 数据库用于缓冲数据的系统内存量。 它是可供所有数据库进程访问的集中式内存池。
需要数据时，数据库进程首先检查共享缓冲区。 如果存在所需的数据，会快速检索此数据，并绕过更耗时的磁盘读取。 共享缓冲区在数据库进程和磁盘之间充当中介，并有效地减少所需的 I/O 操作数。
特定于 Azure 的注释
预配 Azure Database for PostgreSQL 灵活服务器的实例时，会根据为其计算选择的产品名称计算 shared_buffers 参数的默认值。 如果对支持该灵活服务器的计算进行任何后续产品选择更改，该实例的 shared_buffers 服务器参数的默认值不受任何影响。
每次更改分配给实例的产品时，还应根据以下公式中的值调整 shared_buffers 参数的值。
对于内存最多 2 GiB 的虚拟机，用于计算 shared_buffers 的值的公式是 memoryGib * 16384。
对于超过 2 GiB 的虚拟机，用于计算 shared_buffers 的值的公式是 memoryGib * 32768。
根据上一个公式，下表列出了此服务器参数将设置为的值，具体取决于预配的内存量：
| 内存大小 | shared_buffers |
|---|---|
| 2 GiB | 32768 |
| 4 GiB | 131072 |
| 8 GiB | 262144 |
| 16 GiB | 524288 |
| 32 GiB | 1048576 |
| 48 GiB | 1572864 |
| 64 GiB | 2097152 |
| 80 GiB | 2621440 |
| 128 GiB | 4194304 |
| 160 GiB | 5242880 |
| 192 GiB | 6291456 |
| 256 GiB | 8388608 |
| 384 GiB | 12582912 |
| 432 GiB | 14155776 |
| 672 GiB | 22020096 |
shared_memory_type
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 选择用于主共享内存区域的共享内存实现。 |
| 数据类型 | 枚举 |
| 默认值 | mmap |
| 允许的值 | mmap |
| 参数类型 | （只读） |
| 文档 | shared_memory_type |
temp_buffers
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置每个数据库会话使用的临时缓冲区数量上限。 |
| 数据类型 | integer |
| 默认值 | 1024 |
| 允许的值 | 100-1073741823 |
| 参数类型 | 动态 |
| 文档 | temp_buffers |
work_mem
| Attribute | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置写入到临时磁盘文件之前内部排序操作和哈希表要使用的内存量。 |
| 数据类型 | integer |
| 默认值 | 4096 |
| 允许的值 | 4096-2097151 |
| 参数类型 | 动态 |
| 文档 | work_mem |
说明
PostgreSQL 中的 work_mem 参数可控制在每个数据库会话的专用内存区域中为某些内部操作分配的内存量。 这些操作的示例包括排序和哈希处理。
与共享内存区域中的共享缓冲区不同，work_mem 是在每个会话或每个查询的专用内存空间中分配的。 通过设置足够的 work_mem 大小，可以显著提高这些操作的效率，并减少将临时数据写入磁盘的需求。
要点
- 专用连接内存：
work_mem是每个数据库会话使用的专用内存的一部分。 此内存不同于shared_buffers使用的共享内存区域。 - 特定于查询的用法：并非所有会话或查询都使用
work_mem。 简单的查询（例如SELECT 1）不太可能需要work_mem。 但是，涉及排序或哈希处理等操作的复杂查询可能使用work_mem的一个或多个区块。 - 并行操作：对于跨多个并行后端的查询，每个后端可能会使用
work_mem的一个或多个区块。
监视和调整 work_mem
必须持续监视系统性能，并根据需要调整 work_mem，主要是在与排序或哈希处理操作相关的查询执行时间缓慢时。 下面是使用 Azure 门户中提供的工具监视性能的方法：
- 查询性能见解：查看“按临时文件数排名靠前的查询”选项卡，以确定生成临时文件的查询。 这种情况表明，可能需要增加
work_mem。 - 故障排除指南：使用故障排除指南中的“大量临时文件”选项卡来确定有问题的查询。
精细调整
在管理 work_mem 参数时，采用精细调整方法通常比设置全局值更高效。 此方法可确保根据进程和用户的特定需求明智地分配内存。 它还将遇到内存不足问题的风险降到最低。 下面是实现这一点的步骤：
用户级别：如果特定用户主要涉及聚合或报告任务（内存密集型任务），请考虑自定义该用户的
work_mem值。 使用ALTER ROLE命令提高用户操作的性能。函数/过程级别：如果特定函数或过程生成大量临时文件，那么增加特定函数或过程级别的
work_mem值可能会有所帮助。 使用ALTER FUNCTION或ALTER PROCEDURE命令专门为这些操作分配更多内存。数据库级别：如果只有特定数据库生成大量临时文件，请在数据库级别更改
work_mem。全局级别：如果系统分析显示大多数查询生成小型临时文件，而只有少数查询创建大型临时文件，那么最好全局调高
work_mem值。 此操作可促使在内存中处理大多数查询，这样就可避免基于磁盘的操作并提高效率。 但是，请始终谨慎操作并监视服务器上的内存利用率，确保它可处理增加的work_mem值。
确定排序操作的最小 work_mem 值
若要查找特定查询的最小 work_mem 值，尤其是在排序过程中生成临时磁盘文件的查询，请先考虑在查询执行期间生成的临时文件大小。 例如，如果一个查询生成一个 20 MB 的临时文件：
- 使用 psql 或偏好的 PostgreSQL 客户端连接到数据库。
- 设置略高于 20 MB 的初始
work_mem值，以便在内存中处理时考虑到额外的标头。 使用SET work_mem TO '25MB'等命令。 - 在同一会话上对有问题的查询运行
EXPLAIN ANALYZE。 - 查看
"Sort Method: quicksort Memory: xkB"的输出。 如果指示"external merge Disk: xkB"，请以增量方式增加work_mem值并重新测试，直到出现"quicksort Memory"。 出现"quicksort Memory"即表示查询现在内存中运行。 - 通过此方法确定值后，可以全局应用该值，也可在更精细的级别应用它（如上所述）来满足你的操作需求。
autovacuum_work_mem
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置每个 autovacuum 工作进程要使用的最大内存。 |
| 数据类型 | integer |
| 默认值 | -1 |
| 允许的值 | -1-2097151 |
| 参数类型 | 动态 |
| 文档 | autovacuum_work_mem |
dynamic_shared_memory_type
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 选择使用的动态共享内存实现。 |
| 数据类型 | 枚举 |
| 默认值 | posix |
| 允许的值 | posix |
| 参数类型 | （只读） |
| 文档 | dynamic_shared_memory_type |
hash_mem_multiplier
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 要用于哈希表的多个 work_mem。 |
| 数据类型 | numeric |
| 默认值 | 1 |
| 允许的值 | 1-1000 |
| 参数类型 | 动态 |
| 文档 | hash_mem_multiplier |
huge_pages
| Attribute | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 允许/禁止使用大型内存页。 此设置不适用于少于 4 个 vCore 的服务器。 |
| 数据类型 | 枚举 |
| 默认值 | try |
| 允许的值 | on,off,try |
| 参数类型 | static |
| 文档 | huge_pages |
说明
通过大型页面功能，可以在较大的块中管理内存。 通常可管理最大 2 MB 的块，而不是标准的 4 KB 页面。
使用大型页面可提供有效分流 CPU 的性能优势：
- 它们减少了与内存管理任务相关的开销，例如更少的转换后备缓冲区 (TLB) 未命中。
- 它们缩短了内存管理所需的时间。
具体来说，在 PostgreSQL 中，只能将大型页面用于共享内存区域。 共享内存区域的很大一部分分配给了共享缓冲区。
另一个优点是，大型页面可阻止将共享内存区域交换到磁盘，这进一步稳定了性能。
建议
- 对于具有大量内存资源的服务器，请不要禁用大型页面。 禁用大型页面可能会损害性能。
- 如果一开始使用不支持大型页面的较小服务器，但预计会纵向扩展到支持大型页面的服务器，那么请将
huge_pages设置保留为TRY，以保证无缝转换和最佳性能。
特定于 Azure 的注释
对于具有 4 个或更多 vCore 的服务器，会从基础操作系统自动分配大型页面。 此功能不适用于少于 4 个 vCore 的服务器。 如果更改了任何共享内存设置，则会自动调整大型页面数量，包括更改 shared_buffers。
maintenance_work_mem
| Attribute | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置用于维护操作（如 VACUUM、“创建索引”）的最大内存。 |
| 数据类型 | integer |
| 默认值 | 取决于分配给服务器的资源（vCore、RAM 或磁盘空间）。 |
| 允许的值 | 1024-2097151 |
| 参数类型 | 动态 |
| 文档 | maintenance_work_mem |
说明
maintenance_work_mem 是 PostgreSQL 中的一个配置参数。 它可控制为维护操作（例如 VACUUM、CREATE INDEX 和 ALTER TABLE）分配的内存量。 与影响查询操作内存分配的 work_mem 不同，maintenance_work_mem 是为维护和优化数据库结构的任务保留的。
要点
- Vacuum 内存上限：如果想要通过增加
maintenance_work_mem来更快地清理死元组，请注意，VACUUM对于收集死元组标识符有内置限制。 对于此过程，只能使用最多 1 GB 的内存。 - autovacuum 的内存分离：可以使用
autovacuum_work_mem设置单独控制 autovacuum 操作使用的内存。 此设置充当maintenance_work_mem的子集。 你可以决定在不影响其他维护任务和数据定义操作的内存分配的情况下 autovacuum 使用的内存量。
特定于 Azure 的注释
预配 Azure Database for PostgreSQL 灵活服务器的实例时，会根据为其计算选择的产品名称计算 maintenance_work_mem 参数的默认值。 如果对支持该灵活服务器的计算进行任何后续产品选择更改，该实例的 maintenance_work_mem 服务器参数的默认值不受任何影响。
每次更改分配给实例的产品时，还应根据以下公式中的值调整 maintenance_work_mem 参数的值。
用于计算 maintenance_work_mem 的值的公式是 (long)(82.5 * ln(memoryGiB) + 40) * 1024。
根据上一个公式，下表列出了此服务器参数将设置为的值，具体取决于预配的内存量：
| 内存大小 | maintenance_work_mem |
|---|---|
| 2 GiB | 99328 KiB |
| 4 GiB | 157696 KiB |
| 8 GiB | 216064 KiB |
| 16 GiB | 274432 KiB |
| 32 GiB | 332800 KiB |
| 48 GiB | 367616 KiB |
| 64 GiB | 392192 KiB |
| 80 GiB | 410624 KiB |
| 128 GiB | 450560 KiB |
| 160 GiB | 468992 KiB |
| 192 GiB | 484352 KiB |
| 256 GiB | 508928 KiB |
| 384 GiB | 542720 KiB |
| 432 GiB | 552960 KiB |
| 672 GiB | 590848 KiB |
max_prepared_transactions
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置同时准备的事务数量上限。 运行副本服务器时，必须将此参数设置为与主服务器上的值相同或更高的值。 |
| 数据类型 | integer |
| 默认值 | 0 |
| 允许的值 | 0-262143 |
| 参数类型 | static |
| 文档 | max_prepared_transactions |
max_stack_depth
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置最大堆栈深度（以 KB 为单位）。 |
| 数据类型 | integer |
| 默认值 | 2048 |
| 允许的值 | 2048 |
| 参数类型 | （只读） |
| 文档 | max_stack_depth |
shared_buffers
| Attribute | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置服务器使用的共享内存缓冲区数。 单位为 8kb。 允许的值在 10% - 75% 的可用内存范围内。 |
| 数据类型 | integer |
| 默认值 | 取决于分配给服务器的资源（vCore、RAM 或磁盘空间）。 |
| 允许的值 | 16-1073741823 |
| 参数类型 | static |
| 文档 | shared_buffers |
说明
shared_buffers 配置参数确定分配给 PostgreSQL 数据库用于缓冲数据的系统内存量。 它是可供所有数据库进程访问的集中式内存池。
需要数据时，数据库进程首先检查共享缓冲区。 如果存在所需的数据，会快速检索此数据，并绕过更耗时的磁盘读取。 共享缓冲区在数据库进程和磁盘之间充当中介，并有效地减少所需的 I/O 操作数。
特定于 Azure 的注释
预配 Azure Database for PostgreSQL 灵活服务器的实例时，会根据为其计算选择的产品名称计算 shared_buffers 参数的默认值。 如果对支持该灵活服务器的计算进行任何后续产品选择更改，该实例的 shared_buffers 服务器参数的默认值不受任何影响。
每次更改分配给实例的产品时，还应根据以下公式中的值调整 shared_buffers 参数的值。
对于内存最多 2 GiB 的虚拟机，用于计算 shared_buffers 的值的公式是 memoryGib * 16384。
对于超过 2 GiB 的虚拟机，用于计算 shared_buffers 的值的公式是 memoryGib * 32768。
根据上一个公式，下表列出了此服务器参数将设置为的值，具体取决于预配的内存量：
| 内存大小 | shared_buffers |
|---|---|
| 2 GiB | 32768 |
| 4 GiB | 131072 |
| 8 GiB | 262144 |
| 16 GiB | 524288 |
| 32 GiB | 1048576 |
| 48 GiB | 1572864 |
| 64 GiB | 2097152 |
| 80 GiB | 2621440 |
| 128 GiB | 4194304 |
| 160 GiB | 5242880 |
| 192 GiB | 6291456 |
| 256 GiB | 8388608 |
| 384 GiB | 12582912 |
| 432 GiB | 14155776 |
| 672 GiB | 22020096 |
shared_memory_type
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 选择用于主共享内存区域的共享内存实现。 |
| 数据类型 | 枚举 |
| 默认值 | mmap |
| 允许的值 | mmap |
| 参数类型 | （只读） |
| 文档 | shared_memory_type |
temp_buffers
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置每个数据库会话使用的临时缓冲区数量上限。 |
| 数据类型 | integer |
| 默认值 | 1024 |
| 允许的值 | 100-1073741823 |
| 参数类型 | 动态 |
| 文档 | temp_buffers |
work_mem
| Attribute | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置写入到临时磁盘文件之前内部排序操作和哈希表要使用的内存量。 |
| 数据类型 | integer |
| 默认值 | 4096 |
| 允许的值 | 4096-2097151 |
| 参数类型 | 动态 |
| 文档 | work_mem |
说明
PostgreSQL 中的 work_mem 参数可控制在每个数据库会话的专用内存区域中为某些内部操作分配的内存量。 这些操作的示例包括排序和哈希处理。
与共享内存区域中的共享缓冲区不同，work_mem 是在每个会话或每个查询的专用内存空间中分配的。 通过设置足够的 work_mem 大小，可以显著提高这些操作的效率，并减少将临时数据写入磁盘的需求。
要点
- 专用连接内存：
work_mem是每个数据库会话使用的专用内存的一部分。 此内存不同于shared_buffers使用的共享内存区域。 - 特定于查询的用法：并非所有会话或查询都使用
work_mem。 简单的查询（例如SELECT 1）不太可能需要work_mem。 但是，涉及排序或哈希处理等操作的复杂查询可能使用work_mem的一个或多个区块。 - 并行操作：对于跨多个并行后端的查询，每个后端可能会使用
work_mem的一个或多个区块。
监视和调整 work_mem
必须持续监视系统性能，并根据需要调整 work_mem，主要是在与排序或哈希处理操作相关的查询执行时间缓慢时。 下面是使用 Azure 门户中提供的工具监视性能的方法：
- 查询性能见解：查看“按临时文件数排名靠前的查询”选项卡，以确定生成临时文件的查询。 这种情况表明，可能需要增加
work_mem。 - 故障排除指南：使用故障排除指南中的“大量临时文件”选项卡来确定有问题的查询。
精细调整
在管理 work_mem 参数时，采用精细调整方法通常比设置全局值更高效。 此方法可确保根据进程和用户的特定需求明智地分配内存。 它还将遇到内存不足问题的风险降到最低。 下面是实现这一点的步骤：
用户级别：如果特定用户主要涉及聚合或报告任务（内存密集型任务），请考虑自定义该用户的
work_mem值。 使用ALTER ROLE命令提高用户操作的性能。函数/过程级别：如果特定函数或过程生成大量临时文件，那么增加特定函数或过程级别的
work_mem值可能会有所帮助。 使用ALTER FUNCTION或ALTER PROCEDURE命令专门为这些操作分配更多内存。数据库级别：如果只有特定数据库生成大量临时文件，请在数据库级别更改
work_mem。全局级别：如果系统分析显示大多数查询生成小型临时文件，而只有少数查询创建大型临时文件，那么最好全局调高
work_mem值。 此操作可促使在内存中处理大多数查询，这样就可避免基于磁盘的操作并提高效率。 但是，请始终谨慎操作并监视服务器上的内存利用率，确保它可处理增加的work_mem值。
确定排序操作的最小 work_mem 值
若要查找特定查询的最小 work_mem 值，尤其是在排序过程中生成临时磁盘文件的查询，请先考虑在查询执行期间生成的临时文件大小。 例如，如果一个查询生成一个 20 MB 的临时文件：
- 使用 psql 或偏好的 PostgreSQL 客户端连接到数据库。
- 设置略高于 20 MB 的初始
work_mem值，以便在内存中处理时考虑到额外的标头。 使用SET work_mem TO '25MB'等命令。 - 在同一会话上对有问题的查询运行
EXPLAIN ANALYZE。 - 查看
"Sort Method: quicksort Memory: xkB"的输出。 如果指示"external merge Disk: xkB"，请以增量方式增加work_mem值并重新测试，直到出现"quicksort Memory"。 出现"quicksort Memory"即表示查询现在内存中运行。 - 通过此方法确定值后，可以全局应用该值，也可在更精细的级别应用它（如上所述）来满足你的操作需求。
autovacuum_work_mem
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置每个 autovacuum 工作进程要使用的最大内存。 |
| 数据类型 | integer |
| 默认值 | -1 |
| 允许的值 | -1-2097151 |
| 参数类型 | 动态 |
| 文档 | autovacuum_work_mem |
dynamic_shared_memory_type
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 选择使用的动态共享内存实现。 |
| 数据类型 | 枚举 |
| 默认值 | posix |
| 允许的值 | posix |
| 参数类型 | （只读） |
| 文档 | dynamic_shared_memory_type |
huge_pages
| Attribute | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 允许/禁止使用大型内存页。 此设置不适用于少于 4 个 vCore 的服务器。 |
| 数据类型 | 枚举 |
| 默认值 | try |
| 允许的值 | on,off,try |
| 参数类型 | static |
| 文档 | huge_pages |
说明
通过大型页面功能，可以在较大的块中管理内存。 通常可管理最大 2 MB 的块，而不是标准的 4 KB 页面。
使用大型页面可提供有效分流 CPU 的性能优势：
- 它们减少了与内存管理任务相关的开销，例如更少的转换后备缓冲区 (TLB) 未命中。
- 它们缩短了内存管理所需的时间。
具体来说，在 PostgreSQL 中，只能将大型页面用于共享内存区域。 共享内存区域的很大一部分分配给了共享缓冲区。
另一个优点是，大型页面可阻止将共享内存区域交换到磁盘，这进一步稳定了性能。
建议
- 对于具有大量内存资源的服务器，请不要禁用大型页面。 禁用大型页面可能会损害性能。
- 如果一开始使用不支持大型页面的较小服务器，但预计会纵向扩展到支持大型页面的服务器，那么请将
huge_pages设置保留为TRY，以保证无缝转换和最佳性能。
特定于 Azure 的注释
对于具有 4 个或更多 vCore 的服务器，会从基础操作系统自动分配大型页面。 此功能不适用于少于 4 个 vCore 的服务器。 如果更改了任何共享内存设置，则会自动调整大型页面数量，包括更改 shared_buffers。
maintenance_work_mem
| Attribute | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置用于维护操作（如 VACUUM、“创建索引”）的最大内存。 |
| 数据类型 | integer |
| 默认值 | 取决于分配给服务器的资源（vCore、RAM 或磁盘空间）。 |
| 允许的值 | 1024-2097151 |
| 参数类型 | 动态 |
| 文档 | maintenance_work_mem |
说明
maintenance_work_mem 是 PostgreSQL 中的一个配置参数。 它可控制为维护操作（例如 VACUUM、CREATE INDEX 和 ALTER TABLE）分配的内存量。 与影响查询操作内存分配的 work_mem 不同，maintenance_work_mem 是为维护和优化数据库结构的任务保留的。
要点
- Vacuum 内存上限：如果想要通过增加
maintenance_work_mem来更快地清理死元组，请注意，VACUUM对于收集死元组标识符有内置限制。 对于此过程，只能使用最多 1 GB 的内存。 - autovacuum 的内存分离：可以使用
autovacuum_work_mem设置单独控制 autovacuum 操作使用的内存。 此设置充当maintenance_work_mem的子集。 你可以决定在不影响其他维护任务和数据定义操作的内存分配的情况下 autovacuum 使用的内存量。
特定于 Azure 的注释
预配 Azure Database for PostgreSQL 灵活服务器的实例时，会根据为其计算选择的产品名称计算 maintenance_work_mem 参数的默认值。 如果对支持该灵活服务器的计算进行任何后续产品选择更改，该实例的 maintenance_work_mem 服务器参数的默认值不受任何影响。
每次更改分配给实例的产品时，还应根据以下公式中的值调整 maintenance_work_mem 参数的值。
用于计算 maintenance_work_mem 的值的公式是 (long)(82.5 * ln(memoryGiB) + 40) * 1024。
根据上一个公式，下表列出了此服务器参数将设置为的值，具体取决于预配的内存量：
| 内存大小 | maintenance_work_mem |
|---|---|
| 2 GiB | 99328 KiB |
| 4 GiB | 157696 KiB |
| 8 GiB | 216064 KiB |
| 16 GiB | 274432 KiB |
| 32 GiB | 332800 KiB |
| 48 GiB | 367616 KiB |
| 64 GiB | 392192 KiB |
| 80 GiB | 410624 KiB |
| 128 GiB | 450560 KiB |
| 160 GiB | 468992 KiB |
| 192 GiB | 484352 KiB |
| 256 GiB | 508928 KiB |
| 384 GiB | 542720 KiB |
| 432 GiB | 552960 KiB |
| 672 GiB | 590848 KiB |
max_prepared_transactions
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置同时准备的事务数量上限。 运行副本服务器时，必须将此参数设置为与主服务器上的值相同或更高的值。 |
| 数据类型 | integer |
| 默认值 | 0 |
| 允许的值 | 0-262143 |
| 参数类型 | static |
| 文档 | max_prepared_transactions |
max_stack_depth
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置最大堆栈深度（以 KB 为单位）。 |
| 数据类型 | integer |
| 默认值 | 2048 |
| 允许的值 | 2048 |
| 参数类型 | （只读） |
| 文档 | max_stack_depth |
shared_buffers
| Attribute | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置服务器使用的共享内存缓冲区数。 单位为 8kb。 允许的值在 10% - 75% 的可用内存范围内。 |
| 数据类型 | integer |
| 默认值 | 取决于分配给服务器的资源（vCore、RAM 或磁盘空间）。 |
| 允许的值 | 16-1073741823 |
| 参数类型 | static |
| 文档 | shared_buffers |
说明
shared_buffers 配置参数确定分配给 PostgreSQL 数据库用于缓冲数据的系统内存量。 它是可供所有数据库进程访问的集中式内存池。
需要数据时，数据库进程首先检查共享缓冲区。 如果存在所需的数据，会快速检索此数据，并绕过更耗时的磁盘读取。 共享缓冲区在数据库进程和磁盘之间充当中介，并有效地减少所需的 I/O 操作数。
特定于 Azure 的注释
预配 Azure Database for PostgreSQL 灵活服务器的实例时，会根据为其计算选择的产品名称计算 shared_buffers 参数的默认值。 如果对支持该灵活服务器的计算进行任何后续产品选择更改，该实例的 shared_buffers 服务器参数的默认值不受任何影响。
每次更改分配给实例的产品时，还应根据以下公式中的值调整 shared_buffers 参数的值。
对于内存最多 2 GiB 的虚拟机，用于计算 shared_buffers 的值的公式是 memoryGib * 16384。
对于超过 2 GiB 的虚拟机，用于计算 shared_buffers 的值的公式是 memoryGib * 32768。
根据上一个公式，下表列出了此服务器参数将设置为的值，具体取决于预配的内存量：
| 内存大小 | shared_buffers |
|---|---|
| 2 GiB | 32768 |
| 4 GiB | 131072 |
| 8 GiB | 262144 |
| 16 GiB | 524288 |
| 32 GiB | 1048576 |
| 48 GiB | 1572864 |
| 64 GiB | 2097152 |
| 80 GiB | 2621440 |
| 128 GiB | 4194304 |
| 160 GiB | 5242880 |
| 192 GiB | 6291456 |
| 256 GiB | 8388608 |
| 384 GiB | 12582912 |
| 432 GiB | 14155776 |
| 672 GiB | 22020096 |
temp_buffers
| 属性 | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置每个数据库会话使用的临时缓冲区数量上限。 |
| 数据类型 | integer |
| 默认值 | 1024 |
| 允许的值 | 100-1073741823 |
| 参数类型 | 动态 |
| 文档 | temp_buffers |
work_mem
| Attribute | 值 |
|---|---|
| 类别 | 资源使用情况/内存 |
| 说明 | 设置写入到临时磁盘文件之前内部排序操作和哈希表要使用的内存量。 |
| 数据类型 | integer |
| 默认值 | 4096 |
| 允许的值 | 4096-2097151 |
| 参数类型 | 动态 |
| 文档 | work_mem |
说明
PostgreSQL 中的 work_mem 参数可控制在每个数据库会话的专用内存区域中为某些内部操作分配的内存量。 这些操作的示例包括排序和哈希处理。
与共享内存区域中的共享缓冲区不同，work_mem 是在每个会话或每个查询的专用内存空间中分配的。 通过设置足够的 work_mem 大小，可以显著提高这些操作的效率，并减少将临时数据写入磁盘的需求。
要点
- 专用连接内存：
work_mem是每个数据库会话使用的专用内存的一部分。 此内存不同于shared_buffers使用的共享内存区域。 - 特定于查询的用法：并非所有会话或查询都使用
work_mem。 简单的查询（例如SELECT 1）不太可能需要work_mem。 但是，涉及排序或哈希处理等操作的复杂查询可能使用work_mem的一个或多个区块。 - 并行操作：对于跨多个并行后端的查询，每个后端可能会使用
work_mem的一个或多个区块。
监视和调整 work_mem
必须持续监视系统性能，并根据需要调整 work_mem，主要是在与排序或哈希处理操作相关的查询执行时间缓慢时。 下面是使用 Azure 门户中提供的工具监视性能的方法：
- 查询性能见解：查看“按临时文件数排名靠前的查询”选项卡，以确定生成临时文件的查询。 这种情况表明，可能需要增加
work_mem。 - 故障排除指南：使用故障排除指南中的“大量临时文件”选项卡来确定有问题的查询。
精细调整
在管理 work_mem 参数时，采用精细调整方法通常比设置全局值更高效。 此方法可确保根据进程和用户的特定需求明智地分配内存。 它还将遇到内存不足问题的风险降到最低。 下面是实现这一点的步骤：
用户级别：如果特定用户主要涉及聚合或报告任务（内存密集型任务），请考虑自定义该用户的
work_mem值。 使用ALTER ROLE命令提高用户操作的性能。函数/过程级别：如果特定函数或过程生成大量临时文件，那么增加特定函数或过程级别的
work_mem值可能会有所帮助。 使用ALTER FUNCTION或ALTER PROCEDURE命令专门为这些操作分配更多内存。数据库级别：如果只有特定数据库生成大量临时文件，请在数据库级别更改
work_mem。全局级别：如果系统分析显示大多数查询生成小型临时文件，而只有少数查询创建大型临时文件，那么最好全局调高
work_mem值。 此操作可促使在内存中处理大多数查询，这样就可避免基于磁盘的操作并提高效率。 但是，请始终谨慎操作并监视服务器上的内存利用率，确保它可处理增加的work_mem值。
确定排序操作的最小 work_mem 值
若要查找特定查询的最小 work_mem 值，尤其是在排序过程中生成临时磁盘文件的查询，请先考虑在查询执行期间生成的临时文件大小。 例如，如果一个查询生成一个 20 MB 的临时文件：
- 使用 psql 或偏好的 PostgreSQL 客户端连接到数据库。
- 设置略高于 20 MB 的初始
work_mem值，以便在内存中处理时考虑到额外的标头。 使用SET work_mem TO '25MB'等命令。 - 在同一会话上对有问题的查询运行
EXPLAIN ANALYZE。 - 查看
"Sort Method: quicksort Memory: xkB"的输出。 如果指示"external merge Disk: xkB"，请以增量方式增加work_mem值并重新测试，直到出现"quicksort Memory"。 出现"quicksort Memory"即表示查询现在内存中运行。 - 通过此方法确定值后，可以全局应用该值，也可在更精细的级别应用它（如上所述）来满足你的操作需求。