#------------------------------------------------------------------------------
# QUERY TUNING
#------------------------------------------------------------------------------
# - Planner Method Configuration -
# 允许使用相关的执行计划
#enable_bitmapscan = on
# bitmap-scan plan
#enable_hashagg = on
# hashed aggregation plan
# enable_gathermerge = on
# gather merge plan
#enable_hashjoin = on
# hash-join plan
#enable_indexscan = on
# index-scan plan
#enable_indexonlyscan = on
# index-only-scan plan
#enable_material = on
# materialization
#enable_mergejoin = on
# merge-join plan
#enable_nestloop = on
# nested-loop
#enable_seqscan = on
# sequential scan plan
#enable_sort = on
# explicit sort steps
#enable_tidscan = on
# TID scan plan
# - Planner Cost Constants -
# planer对磁盘页面获取成本的估计。
#seq_page_cost = 1.0 # measured on an arbitrary scale
# planer非顺序获取的磁盘页的成本的估计
# 相对于seq_page_cost降低该值将导致系统更喜欢索引扫描；提高它会使索引扫描看起来相对昂贵。
# 可以将这两个值一起提升或降低，以改变磁盘I/O成本相对于CPU成本的重要性
#random_page_cost = 4.0 # same scale as above
# 计划在查询过程中处理每一行的成本的估计值。
#cpu_tuple_cost = 0.01 # same scale as above
# 在索引扫描过程中，设置每个索引条目处理成本的计划者的估计值。
#cpu_index_tuple_cost = 0.005 # same scale as above
# 对每一个操作符或在查询过程中执行的函数的处理成本的估计。
#cpu_operator_cost = 0.0025 # same scale as above
# planer 从一个并行worker进程转移到另一个进程的一个元组的代价的估计。
#parallel_tuple_cost = 0.1 # same scale as above
# 对并行worker processes的成本估计
#parallel_setup_cost = 1000.0 # same scale as above
# 必须扫描的表数据的最小量，以便并行扫描被考虑。对于并行顺序扫描，扫描的表数据的量总是等于表的大小，但是当使用索引时，扫描的表数据的量通常会减少。
#min_parallel_table_scan_size = 8MB
# 设置要扫描的索引数据的最小量，以便进行并行扫描。请注意，并行索引扫描通常不会触及整个索引；这是规划人员认为扫描会真正触及到的页面的数量。
#min_parallel_index_scan_size = 512kB
# 计划者关于单个查询可用的磁盘高速缓存有效大小的假设。这被考虑到使用索引的成本的估计中；
# 更高的值使得它更可能使用索引扫描，较低的值使得它更可能使用顺序扫描。
# 设置此参数时，应同时考虑PostgreSQL的共享缓冲区和内核PostCache数据块的部分，这将用于PostgreSQL数据文件。
# 此外，考虑到不同表上并发查询的预期数量，因为它们必须共享可用空间。此参数对PostgreSQL所分配的共享内存的大小没有影响，
# 也不保留内核磁盘缓存；它仅用于估计目的。系统还不假定数据在查询之间的磁盘缓存中保留。
#effective_cache_size = 4GB
# - Genetic Query Optimizer -
# 基因查询优化器
# 是否开启基因查询优化器
#geqo = on
# 使用遗传查询优化来规划查询，其中至少有许多来自所涉及的项目。对于简单的查询，通常使用常规的穷举搜索规划器是最好的，
# 但是对于具有许多表的查询来说，穷举搜索花费的时间太长，通常比执行次优计划的惩罚要长。因此，查询大小的阈值是管理GEQO使用的便捷方式。
#geqo_threshold = 12
# 控制计划的时间和在GEQO的查询计划质量之间的权衡。
# 较大的值增加了执行查询规划所花费的时间，但也增加了选择有效查询计划的可能性。
#geqo_effort = 5 # range 1-10
# 控制GEQO所使用的池大小，即遗传群体中个体的数量。它必须是至少两个，并且有用的值通常是100到1000。
# 如果将其设置为零（默认设置），则根据geqo_effort和查询中的表数选择合适的值。
#geqo_pool_size = 0 # selects default based on effort
# 控制被GEQO所使用的产生的数，即算法的迭代次数。它必须是至少一个，并且有用的值与池大小在相同的范围内。
# 如果将其设置为零，则基于geqo_pool_size大小选择合适的值。
#geqo_generations = 0 # selects default based on effort
# 控制GEQO所使用的选择偏倚。选择偏倚是群体内的选择性压力。值可以是从1.50到2
#geqo_selection_bias = 2.0 # range 1.5-2.0
# 对照组采用geqo选择随机路径通过连接顺序搜索空间的随机数发生器的初始值。
# 不同的价值变化的连接路径探索，并可能发现更好或更糟的最佳路径。
#geqo_seed = 0.0 # range 0.0-1.0
# - Other Planner Options -
# 设置表列的缺省统计目标，而不是通过ALTER TABLE SET STATISTICS设置列特定目标集。大的值增加了分析所需的时间，但可能会提高PLAN估计质量。
#default_statistics_target = 100 # range 1-10000
# query planer使用表约束来优化查询。ON（检查所有表的约束）、OFF（从不检查约束）和分区（仅检查继承子表和联合所有子查询的约束）。
# 分区是默认设置。它通常与继承和分区表一起使用，以提高性能。
#constraint_exclusion = partition # on, off, or partition
# 设置将检索的游标行的部分的planer的估计。该设置的较小值偏向规划者使用游标的“快速启动”plan，
# 这将快速检索前几行，而可能需要很长时间才能获取所有行。较大的值更强调总估计时间。
#cursor_tuple_fraction = 0.1 # range 0.0-1.0
# 如果从列表中得到的结果将不超过这些多个项目，则planer将合并子查询到上层查询。较小的值减少计划时间，但可能产生劣质查询计划。
#from_collapse_limit = 8
# 当一个不超过这多个项目的列表时，planer将重写显式连接结构（除了完全连接）到来自项目的列表。较小的值减少计划时间，但可能产生劣质查询计划。
#join_collapse_limit = 8 # 1 disables collapsing of explicit
# JOIN clauses
# 允许并行查询用于测试目的，即使在没有性能效益的情况下也是如此。
# 更具体地说，将此值设置为ON将向任何看似安全的查询计划的顶部添加一个聚集节点，以便查询在并行工作器内运行。
# 即使当并行工作者不可用或不能使用时，也会禁止诸如在并行查询上下文中禁止的子事务的操作，除非规划者认为这会导致查询失败。
# 如果设置此选项时发生故障或意外结果，则查询所使用的某些功能可能需要标记为并行不安全（或者，可能并行限制）。
#force_parallel_mode = off