如何在greenplum开源版本中使用pg_stat_statements扩展?
How do I use pg_stat_statements extension in greenplum open source version?
我正在尝试使用修改后的 greenplum 开源版本进行开发。 greenplum版本为Greenplum Database 6.0.0-beta.1 build dev(基于PostgreSQL 9.4.24)。
我想将 pg_stat_statements 扩展添加到我的数据库中,并且在 https://www.postgresql.org/docs/9.5/pgstatstatements.html 之后我设法将其安装到数据库中。但是,此扩展无法按预期工作。它只记录不可计划的查询和实用程序查询。对于修改我的表的所有可计划查询,没有一条记录。
我的问题是,pg_stat_statements 与 greenplum 兼容吗?由于我没有使用官方版本,我想确保原始版本可以与 pg_stat_statements 一起使用。如果是这样,我如何使用它来跟踪 greeplum 中的所有 sql 查询?谢谢
下面是一个不记录我的 select 查询的例子。
postgres=# select pg_stat_statements_reset();
pg_stat_statements_reset
--------------------------
(1 row)
postgres=# select query from pg_stat_statements;
query
------------------------------------
select pg_stat_statements_reset();
(1 row)
postgres=# select * from test;
id | num
----+-----
1 | 2
3 | 4
(2 rows)
postgres=# select query from pg_stat_statements;
query
------------------------------------
select pg_stat_statements_reset();
(1 row)
这是我在 greenplum slack 中从@leskin-in 得到的:
I suppose this is currently not possible.
When Greenplum executes "normal" queries, each of Greenplum segments acts as an independent PostgreSQL instance which executes a plan created by GPDB master.
pg_stat_statements tracks resources usage for a single PostgreSQL instance; as a result, in GPDB it is able to track the resources consumption for each segment independently.
There are several complications PostgreSQL pg_stat_statements
does not deal with. An example is that GPDB uses slices. On GPDB segments, these are independent parts of plan trees and are executed as independent queries.
I suppose when a query to pg_stat_statemens is made on GPDB master in current version, the results retrieved are for master only. As "normal" queries are executed in most part by segments, the results are inconsistent with actual resources' consumption by the query.
In open-source Greenplum 5 & 6 there is a Greenplum-specific utility gpperfmon. It provides some of the pg_stat_statements features, and is cluster-aware (shows actual resources consumption for the cluster as a whole, and also several cluster-specific metrics).
我正在尝试使用修改后的 greenplum 开源版本进行开发。 greenplum版本为Greenplum Database 6.0.0-beta.1 build dev(基于PostgreSQL 9.4.24)。
我想将 pg_stat_statements 扩展添加到我的数据库中,并且在 https://www.postgresql.org/docs/9.5/pgstatstatements.html 之后我设法将其安装到数据库中。但是,此扩展无法按预期工作。它只记录不可计划的查询和实用程序查询。对于修改我的表的所有可计划查询,没有一条记录。
我的问题是,pg_stat_statements 与 greenplum 兼容吗?由于我没有使用官方版本,我想确保原始版本可以与 pg_stat_statements 一起使用。如果是这样,我如何使用它来跟踪 greeplum 中的所有 sql 查询?谢谢
下面是一个不记录我的 select 查询的例子。
postgres=# select pg_stat_statements_reset();
pg_stat_statements_reset
--------------------------
(1 row)
postgres=# select query from pg_stat_statements;
query
------------------------------------
select pg_stat_statements_reset();
(1 row)
postgres=# select * from test;
id | num
----+-----
1 | 2
3 | 4
(2 rows)
postgres=# select query from pg_stat_statements;
query
------------------------------------
select pg_stat_statements_reset();
(1 row)
这是我在 greenplum slack 中从@leskin-in 得到的:
I suppose this is currently not possible. When Greenplum executes "normal" queries, each of Greenplum segments acts as an independent PostgreSQL instance which executes a plan created by GPDB master. pg_stat_statements tracks resources usage for a single PostgreSQL instance; as a result, in GPDB it is able to track the resources consumption for each segment independently. There are several complications PostgreSQL
pg_stat_statements
does not deal with. An example is that GPDB uses slices. On GPDB segments, these are independent parts of plan trees and are executed as independent queries. I suppose when a query to pg_stat_statemens is made on GPDB master in current version, the results retrieved are for master only. As "normal" queries are executed in most part by segments, the results are inconsistent with actual resources' consumption by the query. In open-source Greenplum 5 & 6 there is a Greenplum-specific utility gpperfmon. It provides some of the pg_stat_statements features, and is cluster-aware (shows actual resources consumption for the cluster as a whole, and also several cluster-specific metrics).