BUG #13413: pg_stat_statements don't statistics "DEALLOCATE ALL" statements
The following bug has been logged on the website:
Bug reference: 13413
Logged by: lidong.he
Email address: held911@163.com
PostgreSQL version: 9.4.1
Operating system: linux
Description:
this function is ok in pg 9.3.5. But , it does not work in pg 9.4.1. it's
like follow:
b2c_product=# deallocate all;
DEALLOCATE ALL
b2c_product=# select query from pg_stat_statements where query ~*
'deallocate';
query
-------
(0 rows)
b2c_product=# select query from pg_stat_activity where query ~* 'deallocate'
limit 2;
query
-------------------------------------------------------------------------
select query from pg_stat_activity where query ~* 'deallocate' limit 2;
DEALLOCATE ALL;
(2 rows)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
held911@163.com writes:
this function is ok in pg 9.3.5. But , it does not work in pg 9.4.1.
This is not a bug, it's an intentional behavioral change. See the 9.4
release notes:
* Make pg_stat_statements ignore DEALLOCATE commands (Fabien Coelho)
It already ignored PREPARE, as well as planning time in general,
so this seems more consistent.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
This is my fault.I read the 9.4 release partly,not all .
I read the document about the pg_stat_stament like follow:
F.29. pg_stat_statements
The pg_stat_statements module provides a means for tracking execution statistics of all SQL statements executed by a server.
So, I misunderstand it.
Thans for your reply.
best regards
At 2015-06-08 23:08:34, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
Show quoted text
held911@163.com writes:
this function is ok in pg 9.3.5. But , it does not work in pg 9.4.1.
This is not a bug, it's an intentional behavioral change. See the 9.4
release notes:* Make pg_stat_statements ignore DEALLOCATE commands (Fabien Coelho)
It already ignored PREPARE, as well as planning time in general,
so this seems more consistent.regards, tom lane