小编And*_*mar的帖子

当我查询默认跟踪的配置时，它显示已启用：

exec sp_configure 'default trace enabled';
-->
name                    minimum  maximum  config_value  run_value
default trace enabled         0        1             1          1

但是当我查询sys.traces路径时，它返回一个空行集：

select * from sys.traces;

什么可以解释没有启用的跟踪？

在测试我对SQL 的回答- 从每个组的第一行和最后一行获取数据时，我注意到一些奇怪的事情。在first_value和last_value窗口功能，出现不同的表现。

正如预期的那样，从具有最小值的行中first_value(col1) over (order by col2)找到 的值。但似乎找到了当前行的值。 似乎与其操作的组或分区无关。col1col2last_value(col1) over (order by col2)last_value

对于下面的查询：

id  Session ID  bal
0   00000002    100
1   00000002    120
2   00000002    140
3   00000001    900
4   00000001    800
5   00000001    500

表达方式：

last_value(bal) over (partition by [Session ID] order by id) as lv

返回与以下内容不同的内容：

first_value(bal) over (partition by [Session ID] order by id DESC) as fv_desc

结果如下（注意lv一组内的值变化）：

lv …

据我了解，当您向 Postgres 发送查询时，例如：

SELECT id FROM table1 WHERE name = $1;

Postgres 将创建一个查询计划。该计划将在同一个会话中为同一个查询缓存。但是如果你创建一个函数：

CREATE OR REPLACE FUNCTION get_table1 (parname text) RETURNS bigint
LANGUAGE plpgsql AS 
$$BEGIN
  RETURN (SELECT id FROM table1 where name = parname);
END$$;

查询计划将为所有未来的会话缓存。

我想通过检查查询分析器的调用频率来验证这个理论。有没有办法检查 Postgres 解析查询的次数？

如果可能，我想监视每秒 #parses 和最小/最大/平均解析持续时间等内容。

昨晚将我们的数据库从 9.3.5 升级到 9.4.1 后，服务器遇到了高 CPU 峰值。升级是通过 pg_dump 完成的。于是把数据库转成SQL，再导入9.4。

在 CPU 峰值期间，日志中有很多这样的消息：

process X still waiting for ExclusiveLock on extension of relation Y of database Z 
after 1036.234 ms

和：

process X acquired ExclusiveLock on extension of relation Y of database Z
after 2788.050 ms

看起来可疑的是，有时在完全相同的毫秒内有几个完全相同的关系号的“获取”消息。

为什么 Postgres 会在同一毫秒内将一个表增长两次？它可能是一个具有高填充因子的索引吗？

欢迎任何有关如何解决此问题的建议。

PS 我也在Postgres 邮件列表上问过这个问题，如果不行，请告诉我。