13518219792
postgresql（8.2）的配置文件中有一个参数log_min_duration_statement，意思是只log执行时间大于设定值的语句，如果设为0，表示log所有语句；如果设为-1，表示不log任何语句。
创新互联公司是一家专注于成都网站制作、网站建设与策划设计,桦甸网站建设哪家好?创新互联公司做网站,专注于网站建设10余年,网设计领域的专业建站公司;建站业务涵盖:桦甸等地区。桦甸做网站价格咨询:18980820575
看起来，这个配置选项对性能的调整是很有用的，比如可以设置：
log_min_duration_statement = 1000
则只log执行时间大于1s的语句，重点优化这些sql语句就好了。
然而，奇怪的，这个选项不太容易生效！经过反复试验，原来需要如下配置：
#debug_print_parse = off
#debug_print_rewritten = off
#debug_print_plan = off
#debug_pretty_print = off
log_connections = off
#log_disconnections = off
log_duration = off
log_line_prefix = '%t [%p]: [%l-1] ' # Special values:
# %u = user name
# %d = database name
# %r = remote host and port
# %h = remote host
# %p = PID
# %t = timestamp (no milliseconds)
# %m = timestamp with milliseconds
# %i = command tag
# %c = session id
# %l = session line number
# %s = session start timestamp
# %x = transaction id
# %q = stop here in non-session
# processes
# %% = '%'
# e.g. '%u%%%d '
log_statement = 'none' # none, mod, ddl, all
#log_statement = 'all' # none, mod, ddl, all
#log_hostname = off
注意看上面的其中两个选项的设置：
log_duration = off
log_statement = 'none'
这两个选项的意思是不log任何sql语句和执行时间，但是恰恰是关闭了这两个，log_min_duration_statement才会生效！可能postgresql内部 对这两个选项做了“互斥”处理吧。
本节简单介绍了PG查询逻辑优化中的子查询链接(subLink),以EXISTS子链接为例介绍了子查询链接上拉主函数处理逻辑以及使用gdb跟踪分析。
上一节介绍了ANY子链接,本节介绍了EXISTS子链接.
为便于方便解析,根据日志分析,得出查询树如下图所示:
convert_EXISTS_sublink_to_join函数源码:
相关数据结构
1、Var
XX_one_pos
依赖的函数
simplify_EXISTS_query
OffsetVarNodes
IncrementVarSublevelsUp
IncrementVarSublevelsUp
pull_varnos
contain_vars_of_level
query_tree_walker
OffsetVarNodes_walker
query_or_expression_tree_walker
pull_varnos_walker
contain_vars_of_level_walker
expression_tree_walker
目 录
总 结
PostgreSQL 通过调用系统 fsync() 或者其他使得事务内容写入到物理磁盘，这样可以保证操作系统或者数据库出现宕机后，仍然可以恢复到某一个一致性的状态。理论上讲 PostgreSQL 的 fsync 功能关闭，可以实现性能的提升，但是带来的影响就是需要承担数据的丢失，因为出现系统宕机或者数据库崩溃的时候有一些数据是没有落盘的。
本文将验证 fsync 参数的性能影响，以及参数关闭时数据库宕机后的影响。
数据量：1000W
fsync 参数：on
初始化表：user_info
pgbench 压测
pgbench 结果
pgbench 压测
pgbench 结果
数据量：1000W
fsync 参数：off
初始化表：user_info
pgbench 压测
pgbench 结果
pgbench 压测
pgbench 结果
通过对比发现，将 fsync 改为 off，对于读 TPS，参数 fsync 的影响不大，对于写 TPS，性能有一定提升。
现在验证参数关闭时数据库宕机后的影响
首先，使用将数据库性能跑起来
然后，模拟服务器断电
之后，启动数据库
提示信息：比致命错误还过分的错误。
结果：数据库无法启动，原因就是因为无法找到一个有效的 checkpoint 记录，这就是因为 fsync 设置为 off，由于数据库异常宕机导致。可以通过使用 pg_resetxlog 恢复数据库，但是会造成部分数据无法找回，数据丢失；也可以通过备份恢复，同样也会丢失部分数据。
fsync 参数对于读 TPS 的性能影响不大，对于写 TPS 的性能有一些影响，设置为 off，写 TPS 性能有一定提升，但是存在数据库宕机后无法正常启动，即使恢复后启动数据库，也会有数据丢失的很大风险。因此生产环境非必要时，不要将此参数设置为 off，还是使用默认的 on 比较稳妥。
客户新上线了一套监控系统，可以监控到所有的执行慢的SQL，监控到有个批量任务导入大量数据后，进行索引创建。耗时需要几分钟，虽然不影响业务，但是需要整改。
这种问题的处理思路，都是大拆小，搞并发。
在测试环境，创建一个大表进行测试，创建大量的假数据。
创建表
随机字符串生成函数
生成大量的数据
经测试发现这种方法创建数据太慢了，改成使用COPY的方式创建数据。
排查发现random_string效率太低，生成一条数据接近1ms
重新创建表
写程序创建8600万条数据放在test.csv中
导入大量数据
测试基准数据
\timing 开启计时
耗时532824.434 ms
耗时385838.893 ms，提升 38%的性能，非常不错，但是远远不够。
仍然会出发告警。
重新创建表
创建分区
并发创建INDEX，并记录每个分区索引创建的开始时间和结束时间；
耗时 = 最大结束时间 - 最小开始时间 = 137 s，速度提升接近4倍。
顺序创建INDEX，并记录每个分区索引创建的开始时间和结束时间；
耗时 = 每个索引的耗时相加 = 457358.14 ms，速度提升 16.5%
顺序创建INDEX，优化并发
耗时 = 每个索引的耗时相加 = 292027.642 ms, 速度提升接近两倍。
在开启了并发参数的情况下，如果再叠加并发分区INDEX创建，会不会有惊喜呢？
并发创建INDEX，并记录每个分区索引创建的开始时间和结束时间；
耗时 = 最大结束时间 - 最小开始时间 = 141 s，速度还不如默认并发参数下的表现。应该是资源发生争抢导致的，通过系统监控发现CPU已经打满了。
分区并发是目前能想到的最优化手段了。
还需要结合查询的情况进行分析，分区会带来一点点的性能下降是否影响也需要考虑一下。
分区时目前能避开监控报警的唯一手段了，另外还钻了监控报警的空子。
客户的监控是基于单条语句的，单个分区的最大创建时间为47s，控制在分钟以内了。
