Refactor tests of pg_stat_statements for planning, utility and level tracking
pg_stat_statements.sql acts as the main file for all the core tests of
the module, but things have become complicated to follow over the years
as some of the sub-scenarios tested in this file rely on assumptions
that come from completely different areas of it, like a GUC setup or a
relation created previously. For example, row tracking for CTAS/COPY
was looking at the number of plans, which was not necessary, or level
tracking was mixed with checks on planner counts.
This commit refactors the tests of pg_stat_statements, by moving test
cases out of pg_stat_statements.sql into their own file, as of:
- Planning-related tests in planning.sql, for [re]plan counts and
top-level handling. These depend on pg_stat_statements.track_planning.
- Utilities in utility.sql (pg_stat_statements.track_utility), that
includes now the tests for:
-- Row tracking for CTAS, CREATE MATERIALIZED VIEW, COPY.
-- Basic utility statements.
-- SET statements.
- Tracking level, depending on pg_stat_statements.track. This part has
been looking at scenarios with DO blocks, PL functions and SQL
functions.
pg_stat_statements.sql (still named the same for now) still includes
some checks for role-level tracking and WAL generation metrics, that
ought to become independent in the long term for clarity.
While on it, this switches the order of the attributes when querying
pg_stat_statements, the query field becoming last. This makes much
easier the tracking of changes related to normalization, as queries are
the only variable-length attributes queried (unaligned mode would be one
extra choice, but that reduces the checks on the other fields).
Test scenarios and their results match exactly with what was happening
before this commit in terms of calls, number of plans, number of rows,
cached data or level tracking, so this has no effect on the coverage in
terms of what is produced by the reports in the table
pg_stat_statements. A follow-up patch will extend more the tests of
pg_stat_statements around utilities, so this split creates a foundation
for this purpose, without complicating more pg_stat_statements.sql.
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 01:28:29 +01:00
|
|
|
--
|
|
|
|
-- Utility commands
|
|
|
|
--
|
|
|
|
-- These tests require track_utility to be enabled.
|
|
|
|
SET pg_stat_statements.track_utility = TRUE;
|
2023-11-27 01:50:59 +01:00
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
t
|
|
|
|
---
|
|
|
|
t
|
Refactor tests of pg_stat_statements for planning, utility and level tracking
pg_stat_statements.sql acts as the main file for all the core tests of
the module, but things have become complicated to follow over the years
as some of the sub-scenarios tested in this file rely on assumptions
that come from completely different areas of it, like a GUC setup or a
relation created previously. For example, row tracking for CTAS/COPY
was looking at the number of plans, which was not necessary, or level
tracking was mixed with checks on planner counts.
This commit refactors the tests of pg_stat_statements, by moving test
cases out of pg_stat_statements.sql into their own file, as of:
- Planning-related tests in planning.sql, for [re]plan counts and
top-level handling. These depend on pg_stat_statements.track_planning.
- Utilities in utility.sql (pg_stat_statements.track_utility), that
includes now the tests for:
-- Row tracking for CTAS, CREATE MATERIALIZED VIEW, COPY.
-- Basic utility statements.
-- SET statements.
- Tracking level, depending on pg_stat_statements.track. This part has
been looking at scenarios with DO blocks, PL functions and SQL
functions.
pg_stat_statements.sql (still named the same for now) still includes
some checks for role-level tracking and WAL generation metrics, that
ought to become independent in the long term for clarity.
While on it, this switches the order of the attributes when querying
pg_stat_statements, the query field becoming last. This makes much
easier the tracking of changes related to normalization, as queries are
the only variable-length attributes queried (unaligned mode would be one
extra choice, but that reduces the checks on the other fields).
Test scenarios and their results match exactly with what was happening
before this commit in terms of calls, number of plans, number of rows,
cached data or level tracking, so this has no effect on the coverage in
terms of what is produced by the reports in the table
pg_stat_statements. A follow-up patch will extend more the tests of
pg_stat_statements around utilities, so this split creates a foundation
for this purpose, without complicating more pg_stat_statements.sql.
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 01:28:29 +01:00
|
|
|
(1 row)
|
|
|
|
|
Expand regression tests of pg_stat_statements for utility queries
This commit adds more coverage for utility statements so as it is
possible to track down all the effects of query normalization done for
all the queries that use either Const or A_Const nodes, which are the
nodes where normalization makes the most sense as they apply to
constants (well, most of the time, really).
This set of queries is extracted from an analysis done while looking at
full dumps of the regression database when applying different levels of
normalization to either Const or A_Const nodes for utilities, as of a
minimal set of these, for:
- All relkinds (CREATE, ALTER, DROP)
- Policies
- Cursors
- Triggers
- Types
- Rules
- Statistics
- CALL
- Transaction statements (isolation level, options)
- EXPLAIN
- COPY
Note that pg_stat_statements is not switched yet to show any
normalization for utilities, still it improves the default coverage of
the query jumbling code (not by as much as enabling query jumbling on
the main regression test suite, though):
- queryjumblefuncs.funcs.c: 36.8% => 48.5%
- queryjumblefuncs.switch.c: 33.2% => 43.1%
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 02:16:51 +01:00
|
|
|
-- Tables, indexes, triggers
|
|
|
|
CREATE TEMP TABLE tab_stats (a int, b char(20));
|
|
|
|
CREATE INDEX index_stats ON tab_stats(b, (b || 'data1'), (b || 'data2')) WHERE a > 0;
|
|
|
|
ALTER TABLE tab_stats ALTER COLUMN b set default 'a';
|
|
|
|
ALTER TABLE tab_stats ALTER COLUMN b TYPE text USING 'data' || b;
|
|
|
|
ALTER TABLE tab_stats ADD CONSTRAINT a_nonzero CHECK (a <> 0);
|
|
|
|
DROP TABLE tab_stats \;
|
|
|
|
DROP TABLE IF EXISTS tab_stats \;
|
|
|
|
-- This DROP query uses two different strings, still they count as one entry.
|
|
|
|
DROP TABLE IF EXISTS tab_stats \;
|
|
|
|
Drop Table If Exists tab_stats \;
|
|
|
|
SELECT calls, rows, query FROM pg_stat_statements ORDER BY query COLLATE "C";
|
|
|
|
NOTICE: table "tab_stats" does not exist, skipping
|
|
|
|
NOTICE: table "tab_stats" does not exist, skipping
|
|
|
|
NOTICE: table "tab_stats" does not exist, skipping
|
|
|
|
calls | rows | query
|
|
|
|
-------+------+--------------------------------------------------------------------------------------
|
|
|
|
1 | 0 | ALTER TABLE tab_stats ADD CONSTRAINT a_nonzero CHECK (a <> 0)
|
|
|
|
1 | 0 | ALTER TABLE tab_stats ALTER COLUMN b TYPE text USING 'data' || b
|
|
|
|
1 | 0 | ALTER TABLE tab_stats ALTER COLUMN b set default 'a'
|
|
|
|
1 | 0 | CREATE INDEX index_stats ON tab_stats(b, (b || 'data1'), (b || 'data2')) WHERE a > 0
|
|
|
|
1 | 0 | CREATE TEMP TABLE tab_stats (a int, b char(20))
|
|
|
|
3 | 0 | DROP TABLE IF EXISTS tab_stats
|
|
|
|
1 | 0 | DROP TABLE tab_stats
|
2023-11-27 01:50:59 +01:00
|
|
|
1 | 1 | SELECT pg_stat_statements_reset() IS NOT NULL AS t
|
Expand regression tests of pg_stat_statements for utility queries
This commit adds more coverage for utility statements so as it is
possible to track down all the effects of query normalization done for
all the queries that use either Const or A_Const nodes, which are the
nodes where normalization makes the most sense as they apply to
constants (well, most of the time, really).
This set of queries is extracted from an analysis done while looking at
full dumps of the regression database when applying different levels of
normalization to either Const or A_Const nodes for utilities, as of a
minimal set of these, for:
- All relkinds (CREATE, ALTER, DROP)
- Policies
- Cursors
- Triggers
- Types
- Rules
- Statistics
- CALL
- Transaction statements (isolation level, options)
- EXPLAIN
- COPY
Note that pg_stat_statements is not switched yet to show any
normalization for utilities, still it improves the default coverage of
the query jumbling code (not by as much as enabling query jumbling on
the main regression test suite, though):
- queryjumblefuncs.funcs.c: 36.8% => 48.5%
- queryjumblefuncs.switch.c: 33.2% => 43.1%
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 02:16:51 +01:00
|
|
|
(8 rows)
|
|
|
|
|
2023-11-27 01:50:59 +01:00
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
t
|
|
|
|
---
|
|
|
|
t
|
Refactor tests of pg_stat_statements for planning, utility and level tracking
pg_stat_statements.sql acts as the main file for all the core tests of
the module, but things have become complicated to follow over the years
as some of the sub-scenarios tested in this file rely on assumptions
that come from completely different areas of it, like a GUC setup or a
relation created previously. For example, row tracking for CTAS/COPY
was looking at the number of plans, which was not necessary, or level
tracking was mixed with checks on planner counts.
This commit refactors the tests of pg_stat_statements, by moving test
cases out of pg_stat_statements.sql into their own file, as of:
- Planning-related tests in planning.sql, for [re]plan counts and
top-level handling. These depend on pg_stat_statements.track_planning.
- Utilities in utility.sql (pg_stat_statements.track_utility), that
includes now the tests for:
-- Row tracking for CTAS, CREATE MATERIALIZED VIEW, COPY.
-- Basic utility statements.
-- SET statements.
- Tracking level, depending on pg_stat_statements.track. This part has
been looking at scenarios with DO blocks, PL functions and SQL
functions.
pg_stat_statements.sql (still named the same for now) still includes
some checks for role-level tracking and WAL generation metrics, that
ought to become independent in the long term for clarity.
While on it, this switches the order of the attributes when querying
pg_stat_statements, the query field becoming last. This makes much
easier the tracking of changes related to normalization, as queries are
the only variable-length attributes queried (unaligned mode would be one
extra choice, but that reduces the checks on the other fields).
Test scenarios and their results match exactly with what was happening
before this commit in terms of calls, number of plans, number of rows,
cached data or level tracking, so this has no effect on the coverage in
terms of what is produced by the reports in the table
pg_stat_statements. A follow-up patch will extend more the tests of
pg_stat_statements around utilities, so this split creates a foundation
for this purpose, without complicating more pg_stat_statements.sql.
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 01:28:29 +01:00
|
|
|
(1 row)
|
|
|
|
|
Expand regression tests of pg_stat_statements for utility queries
This commit adds more coverage for utility statements so as it is
possible to track down all the effects of query normalization done for
all the queries that use either Const or A_Const nodes, which are the
nodes where normalization makes the most sense as they apply to
constants (well, most of the time, really).
This set of queries is extracted from an analysis done while looking at
full dumps of the regression database when applying different levels of
normalization to either Const or A_Const nodes for utilities, as of a
minimal set of these, for:
- All relkinds (CREATE, ALTER, DROP)
- Policies
- Cursors
- Triggers
- Types
- Rules
- Statistics
- CALL
- Transaction statements (isolation level, options)
- EXPLAIN
- COPY
Note that pg_stat_statements is not switched yet to show any
normalization for utilities, still it improves the default coverage of
the query jumbling code (not by as much as enabling query jumbling on
the main regression test suite, though):
- queryjumblefuncs.funcs.c: 36.8% => 48.5%
- queryjumblefuncs.switch.c: 33.2% => 43.1%
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 02:16:51 +01:00
|
|
|
-- Partitions
|
|
|
|
CREATE TABLE pt_stats (a int, b int) PARTITION BY range (a);
|
|
|
|
CREATE TABLE pt_stats1 (a int, b int);
|
|
|
|
ALTER TABLE pt_stats ATTACH PARTITION pt_stats1 FOR VALUES FROM (0) TO (100);
|
|
|
|
CREATE TABLE pt_stats2 PARTITION OF pt_stats FOR VALUES FROM (100) TO (200);
|
|
|
|
CREATE INDEX pt_stats_index ON ONLY pt_stats (a);
|
|
|
|
CREATE INDEX pt_stats2_index ON ONLY pt_stats2 (a);
|
|
|
|
ALTER INDEX pt_stats_index ATTACH PARTITION pt_stats2_index;
|
|
|
|
DROP TABLE pt_stats;
|
|
|
|
-- Views
|
|
|
|
CREATE VIEW view_stats AS SELECT 1::int AS a, 2::int AS b;
|
|
|
|
ALTER VIEW view_stats ALTER COLUMN a SET DEFAULT 2;
|
|
|
|
DROP VIEW view_stats;
|
|
|
|
-- Foreign tables
|
|
|
|
CREATE FOREIGN DATA WRAPPER wrapper_stats;
|
|
|
|
CREATE SERVER server_stats FOREIGN DATA WRAPPER wrapper_stats;
|
|
|
|
CREATE FOREIGN TABLE foreign_stats (a int) SERVER server_stats;
|
|
|
|
ALTER FOREIGN TABLE foreign_stats ADD COLUMN b integer DEFAULT 1;
|
|
|
|
ALTER FOREIGN TABLE foreign_stats ADD CONSTRAINT b_nonzero CHECK (b <> 0);
|
|
|
|
DROP FOREIGN TABLE foreign_stats;
|
|
|
|
DROP SERVER server_stats;
|
|
|
|
DROP FOREIGN DATA WRAPPER wrapper_stats;
|
|
|
|
-- Functions
|
|
|
|
CREATE FUNCTION func_stats(a text DEFAULT 'a_data', b text DEFAULT lower('b_data'))
|
|
|
|
RETURNS text AS $$ SELECT $1::text || '_' || $2::text; $$ LANGUAGE SQL;
|
|
|
|
DROP FUNCTION func_stats;
|
|
|
|
-- Rules
|
|
|
|
CREATE TABLE tab_rule_stats (a int, b int);
|
|
|
|
CREATE TABLE tab_rule_stats_2 (a int, b int, c int, d int);
|
|
|
|
CREATE RULE rules_stats AS ON INSERT TO tab_rule_stats DO INSTEAD
|
|
|
|
INSERT INTO tab_rule_stats_2 VALUES(new.*, 1, 2);
|
|
|
|
DROP RULE rules_stats ON tab_rule_stats;
|
|
|
|
DROP TABLE tab_rule_stats, tab_rule_stats_2;
|
|
|
|
-- Types
|
|
|
|
CREATE TYPE stats_type as (f1 numeric(35, 6), f2 numeric(35, 2));
|
|
|
|
DROP TYPE stats_type;
|
|
|
|
-- Triggers
|
|
|
|
CREATE TABLE trigger_tab_stats (a int, b int);
|
|
|
|
CREATE FUNCTION trigger_func_stats () RETURNS trigger LANGUAGE plpgsql
|
|
|
|
AS $$ BEGIN return OLD; end; $$;
|
|
|
|
CREATE TRIGGER trigger_tab_stats
|
|
|
|
AFTER UPDATE ON trigger_tab_stats
|
|
|
|
FOR EACH ROW WHEN (OLD.a < 0 AND OLD.b < 1 AND true)
|
|
|
|
EXECUTE FUNCTION trigger_func_stats();
|
|
|
|
DROP TABLE trigger_tab_stats;
|
|
|
|
-- Policies
|
|
|
|
CREATE TABLE tab_policy_stats (a int, b int);
|
|
|
|
CREATE POLICY policy_stats ON tab_policy_stats USING (a = 5) WITH CHECK (b < 5);
|
|
|
|
DROP TABLE tab_policy_stats;
|
|
|
|
-- Statistics
|
|
|
|
CREATE TABLE tab_expr_stats (a int, b int);
|
|
|
|
CREATE STATISTICS tab_expr_stats_1 (mcv) ON a, (2*a), (3*b) FROM tab_expr_stats;
|
|
|
|
DROP TABLE tab_expr_stats;
|
|
|
|
SELECT calls, rows, query FROM pg_stat_statements ORDER BY query COLLATE "C";
|
|
|
|
calls | rows | query
|
|
|
|
-------+------+-------------------------------------------------------------------------------------
|
|
|
|
1 | 0 | ALTER FOREIGN TABLE foreign_stats ADD COLUMN b integer DEFAULT 1
|
|
|
|
1 | 0 | ALTER FOREIGN TABLE foreign_stats ADD CONSTRAINT b_nonzero CHECK (b <> 0)
|
|
|
|
1 | 0 | ALTER INDEX pt_stats_index ATTACH PARTITION pt_stats2_index
|
|
|
|
1 | 0 | ALTER TABLE pt_stats ATTACH PARTITION pt_stats1 FOR VALUES FROM (0) TO (100)
|
|
|
|
1 | 0 | ALTER VIEW view_stats ALTER COLUMN a SET DEFAULT 2
|
|
|
|
1 | 0 | CREATE FOREIGN DATA WRAPPER wrapper_stats
|
|
|
|
1 | 0 | CREATE FOREIGN TABLE foreign_stats (a int) SERVER server_stats
|
|
|
|
1 | 0 | CREATE FUNCTION func_stats(a text DEFAULT 'a_data', b text DEFAULT lower('b_data'))+
|
|
|
|
| | RETURNS text AS $$ SELECT $1::text || '_' || $2::text; $$ LANGUAGE SQL
|
|
|
|
1 | 0 | CREATE FUNCTION trigger_func_stats () RETURNS trigger LANGUAGE plpgsql +
|
|
|
|
| | AS $$ BEGIN return OLD; end; $$
|
|
|
|
1 | 0 | CREATE INDEX pt_stats2_index ON ONLY pt_stats2 (a)
|
|
|
|
1 | 0 | CREATE INDEX pt_stats_index ON ONLY pt_stats (a)
|
|
|
|
1 | 0 | CREATE POLICY policy_stats ON tab_policy_stats USING (a = 5) WITH CHECK (b < 5)
|
|
|
|
1 | 0 | CREATE RULE rules_stats AS ON INSERT TO tab_rule_stats DO INSTEAD +
|
|
|
|
| | INSERT INTO tab_rule_stats_2 VALUES(new.*, 1, 2)
|
|
|
|
1 | 0 | CREATE SERVER server_stats FOREIGN DATA WRAPPER wrapper_stats
|
|
|
|
1 | 0 | CREATE STATISTICS tab_expr_stats_1 (mcv) ON a, (2*a), (3*b) FROM tab_expr_stats
|
|
|
|
1 | 0 | CREATE TABLE pt_stats (a int, b int) PARTITION BY range (a)
|
|
|
|
1 | 0 | CREATE TABLE pt_stats1 (a int, b int)
|
|
|
|
1 | 0 | CREATE TABLE pt_stats2 PARTITION OF pt_stats FOR VALUES FROM (100) TO (200)
|
|
|
|
1 | 0 | CREATE TABLE tab_expr_stats (a int, b int)
|
|
|
|
1 | 0 | CREATE TABLE tab_policy_stats (a int, b int)
|
|
|
|
1 | 0 | CREATE TABLE tab_rule_stats (a int, b int)
|
|
|
|
1 | 0 | CREATE TABLE tab_rule_stats_2 (a int, b int, c int, d int)
|
|
|
|
1 | 0 | CREATE TABLE trigger_tab_stats (a int, b int)
|
|
|
|
1 | 0 | CREATE TRIGGER trigger_tab_stats +
|
|
|
|
| | AFTER UPDATE ON trigger_tab_stats +
|
|
|
|
| | FOR EACH ROW WHEN (OLD.a < 0 AND OLD.b < 1 AND true) +
|
|
|
|
| | EXECUTE FUNCTION trigger_func_stats()
|
|
|
|
1 | 0 | CREATE TYPE stats_type as (f1 numeric(35, 6), f2 numeric(35, 2))
|
|
|
|
1 | 0 | CREATE VIEW view_stats AS SELECT 1::int AS a, 2::int AS b
|
|
|
|
1 | 0 | DROP FOREIGN DATA WRAPPER wrapper_stats
|
|
|
|
1 | 0 | DROP FOREIGN TABLE foreign_stats
|
|
|
|
1 | 0 | DROP FUNCTION func_stats
|
|
|
|
1 | 0 | DROP RULE rules_stats ON tab_rule_stats
|
|
|
|
1 | 0 | DROP SERVER server_stats
|
|
|
|
1 | 0 | DROP TABLE pt_stats
|
|
|
|
1 | 0 | DROP TABLE tab_expr_stats
|
|
|
|
1 | 0 | DROP TABLE tab_policy_stats
|
|
|
|
1 | 0 | DROP TABLE tab_rule_stats, tab_rule_stats_2
|
|
|
|
1 | 0 | DROP TABLE trigger_tab_stats
|
|
|
|
1 | 0 | DROP TYPE stats_type
|
|
|
|
1 | 0 | DROP VIEW view_stats
|
2023-11-27 01:50:59 +01:00
|
|
|
1 | 1 | SELECT pg_stat_statements_reset() IS NOT NULL AS t
|
Expand regression tests of pg_stat_statements for utility queries
This commit adds more coverage for utility statements so as it is
possible to track down all the effects of query normalization done for
all the queries that use either Const or A_Const nodes, which are the
nodes where normalization makes the most sense as they apply to
constants (well, most of the time, really).
This set of queries is extracted from an analysis done while looking at
full dumps of the regression database when applying different levels of
normalization to either Const or A_Const nodes for utilities, as of a
minimal set of these, for:
- All relkinds (CREATE, ALTER, DROP)
- Policies
- Cursors
- Triggers
- Types
- Rules
- Statistics
- CALL
- Transaction statements (isolation level, options)
- EXPLAIN
- COPY
Note that pg_stat_statements is not switched yet to show any
normalization for utilities, still it improves the default coverage of
the query jumbling code (not by as much as enabling query jumbling on
the main regression test suite, though):
- queryjumblefuncs.funcs.c: 36.8% => 48.5%
- queryjumblefuncs.switch.c: 33.2% => 43.1%
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 02:16:51 +01:00
|
|
|
(39 rows)
|
|
|
|
|
2023-11-27 01:50:59 +01:00
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
t
|
|
|
|
---
|
|
|
|
t
|
Expand regression tests of pg_stat_statements for utility queries
This commit adds more coverage for utility statements so as it is
possible to track down all the effects of query normalization done for
all the queries that use either Const or A_Const nodes, which are the
nodes where normalization makes the most sense as they apply to
constants (well, most of the time, really).
This set of queries is extracted from an analysis done while looking at
full dumps of the regression database when applying different levels of
normalization to either Const or A_Const nodes for utilities, as of a
minimal set of these, for:
- All relkinds (CREATE, ALTER, DROP)
- Policies
- Cursors
- Triggers
- Types
- Rules
- Statistics
- CALL
- Transaction statements (isolation level, options)
- EXPLAIN
- COPY
Note that pg_stat_statements is not switched yet to show any
normalization for utilities, still it improves the default coverage of
the query jumbling code (not by as much as enabling query jumbling on
the main regression test suite, though):
- queryjumblefuncs.funcs.c: 36.8% => 48.5%
- queryjumblefuncs.switch.c: 33.2% => 43.1%
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 02:16:51 +01:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- Transaction statements
|
|
|
|
BEGIN;
|
|
|
|
ABORT;
|
|
|
|
BEGIN;
|
|
|
|
ROLLBACK;
|
|
|
|
-- WORK
|
|
|
|
BEGIN WORK;
|
|
|
|
COMMIT WORK;
|
|
|
|
BEGIN WORK;
|
|
|
|
ABORT WORK;
|
|
|
|
-- TRANSACTION
|
|
|
|
BEGIN TRANSACTION;
|
|
|
|
COMMIT TRANSACTION;
|
|
|
|
BEGIN TRANSACTION;
|
|
|
|
ABORT TRANSACTION;
|
|
|
|
-- More isolation levels
|
|
|
|
BEGIN TRANSACTION DEFERRABLE;
|
|
|
|
COMMIT TRANSACTION AND NO CHAIN;
|
|
|
|
BEGIN ISOLATION LEVEL SERIALIZABLE;
|
|
|
|
COMMIT;
|
|
|
|
BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
|
|
|
|
COMMIT;
|
|
|
|
-- List of A_Const nodes, same lists.
|
|
|
|
BEGIN TRANSACTION READ ONLY, READ WRITE, DEFERRABLE, NOT DEFERRABLE;
|
|
|
|
COMMIT;
|
|
|
|
BEGIN TRANSACTION NOT DEFERRABLE, READ ONLY, READ WRITE, DEFERRABLE;
|
|
|
|
COMMIT;
|
|
|
|
SELECT calls, rows, query FROM pg_stat_statements ORDER BY query COLLATE "C";
|
|
|
|
calls | rows | query
|
|
|
|
-------+------+---------------------------------------------------------------------
|
|
|
|
4 | 0 | ABORT
|
|
|
|
6 | 0 | BEGIN
|
|
|
|
2 | 0 | BEGIN ISOLATION LEVEL SERIALIZABLE
|
|
|
|
1 | 0 | BEGIN TRANSACTION DEFERRABLE
|
|
|
|
1 | 0 | BEGIN TRANSACTION NOT DEFERRABLE, READ ONLY, READ WRITE, DEFERRABLE
|
|
|
|
1 | 0 | BEGIN TRANSACTION READ ONLY, READ WRITE, DEFERRABLE, NOT DEFERRABLE
|
|
|
|
7 | 0 | COMMIT WORK
|
2023-11-27 01:50:59 +01:00
|
|
|
1 | 1 | SELECT pg_stat_statements_reset() IS NOT NULL AS t
|
Expand regression tests of pg_stat_statements for utility queries
This commit adds more coverage for utility statements so as it is
possible to track down all the effects of query normalization done for
all the queries that use either Const or A_Const nodes, which are the
nodes where normalization makes the most sense as they apply to
constants (well, most of the time, really).
This set of queries is extracted from an analysis done while looking at
full dumps of the regression database when applying different levels of
normalization to either Const or A_Const nodes for utilities, as of a
minimal set of these, for:
- All relkinds (CREATE, ALTER, DROP)
- Policies
- Cursors
- Triggers
- Types
- Rules
- Statistics
- CALL
- Transaction statements (isolation level, options)
- EXPLAIN
- COPY
Note that pg_stat_statements is not switched yet to show any
normalization for utilities, still it improves the default coverage of
the query jumbling code (not by as much as enabling query jumbling on
the main regression test suite, though):
- queryjumblefuncs.funcs.c: 36.8% => 48.5%
- queryjumblefuncs.switch.c: 33.2% => 43.1%
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 02:16:51 +01:00
|
|
|
(8 rows)
|
|
|
|
|
2023-11-27 01:50:59 +01:00
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
t
|
|
|
|
---
|
|
|
|
t
|
Expand regression tests of pg_stat_statements for utility queries
This commit adds more coverage for utility statements so as it is
possible to track down all the effects of query normalization done for
all the queries that use either Const or A_Const nodes, which are the
nodes where normalization makes the most sense as they apply to
constants (well, most of the time, really).
This set of queries is extracted from an analysis done while looking at
full dumps of the regression database when applying different levels of
normalization to either Const or A_Const nodes for utilities, as of a
minimal set of these, for:
- All relkinds (CREATE, ALTER, DROP)
- Policies
- Cursors
- Triggers
- Types
- Rules
- Statistics
- CALL
- Transaction statements (isolation level, options)
- EXPLAIN
- COPY
Note that pg_stat_statements is not switched yet to show any
normalization for utilities, still it improves the default coverage of
the query jumbling code (not by as much as enabling query jumbling on
the main regression test suite, though):
- queryjumblefuncs.funcs.c: 36.8% => 48.5%
- queryjumblefuncs.switch.c: 33.2% => 43.1%
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 02:16:51 +01:00
|
|
|
(1 row)
|
|
|
|
|
2023-08-12 03:44:15 +02:00
|
|
|
-- Two-phase transactions
|
|
|
|
BEGIN;
|
|
|
|
PREPARE TRANSACTION 'stat_trans1';
|
|
|
|
COMMIT PREPARED 'stat_trans1';
|
|
|
|
BEGIN;
|
|
|
|
PREPARE TRANSACTION 'stat_trans2';
|
|
|
|
ROLLBACK PREPARED 'stat_trans2';
|
|
|
|
SELECT calls, rows, query FROM pg_stat_statements ORDER BY query COLLATE "C";
|
2023-11-27 01:50:59 +01:00
|
|
|
calls | rows | query
|
|
|
|
-------+------+----------------------------------------------------
|
2023-08-12 03:44:15 +02:00
|
|
|
2 | 0 | BEGIN
|
|
|
|
1 | 0 | COMMIT PREPARED $1
|
|
|
|
2 | 0 | PREPARE TRANSACTION $1
|
|
|
|
1 | 0 | ROLLBACK PREPARED $1
|
2023-11-27 01:50:59 +01:00
|
|
|
1 | 1 | SELECT pg_stat_statements_reset() IS NOT NULL AS t
|
2023-08-12 03:44:15 +02:00
|
|
|
(5 rows)
|
|
|
|
|
2023-11-27 01:50:59 +01:00
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
t
|
|
|
|
---
|
|
|
|
t
|
2023-08-12 03:44:15 +02:00
|
|
|
(1 row)
|
|
|
|
|
Show savepoint names as constants in pg_stat_statements
In pg_stat_statements, savepoint names now show up as constants with a
parameter symbol, using as base query string the one added as a new
entry to the PGSS hash table, leading to:
RELEASE $1
ROLLBACK TO $1
SAVEPOINT $1
Applying constants to these query parts is a huge advantage for
workloads that generate randomly savepoint points, like ORMs (Django is
at the origin of this patch). The ODBC driver is a second layer that
likes a lot savepoints, though it does not use a random naming pattern.
A "location" field is added to TransactionStmt, now set only for
savepoints. The savepoint name is ignored by the query jumbling. The
location can be extended to other query patterns, if required, like 2PC
commands. Some tests are added to pg_stat_statements for all the query
patterns supported by the parser.
ROLLBACK, ROLLBACK TO SAVEPOINT and ROLLBACK TRANSACTION TO SAVEPOINT
have the same Node representation, so all these are equivalents. The
same happens for RELEASE and RELEASE SAVEPOINT.
Author: Greg Sabino Mullane
Discussion: https://postgr.es/m/CAKAnmm+2s9PA4OaumwMJReWHk8qvJ_-g1WqxDRDAN1BSUfxyTw@mail.gmail.com
2023-07-27 02:42:33 +02:00
|
|
|
-- Savepoints
|
|
|
|
BEGIN;
|
|
|
|
SAVEPOINT sp1;
|
|
|
|
SAVEPOINT sp2;
|
|
|
|
SAVEPOINT sp3;
|
|
|
|
SAVEPOINT sp4;
|
|
|
|
ROLLBACK TO sp4;
|
|
|
|
ROLLBACK TO SAVEPOINT sp4;
|
|
|
|
ROLLBACK TRANSACTION TO SAVEPOINT sp3;
|
|
|
|
RELEASE sp3;
|
|
|
|
RELEASE SAVEPOINT sp2;
|
|
|
|
ROLLBACK TO sp1;
|
|
|
|
RELEASE SAVEPOINT sp1;
|
|
|
|
COMMIT;
|
|
|
|
SELECT calls, rows, query FROM pg_stat_statements ORDER BY query COLLATE "C";
|
2023-11-27 01:50:59 +01:00
|
|
|
calls | rows | query
|
|
|
|
-------+------+----------------------------------------------------
|
Show savepoint names as constants in pg_stat_statements
In pg_stat_statements, savepoint names now show up as constants with a
parameter symbol, using as base query string the one added as a new
entry to the PGSS hash table, leading to:
RELEASE $1
ROLLBACK TO $1
SAVEPOINT $1
Applying constants to these query parts is a huge advantage for
workloads that generate randomly savepoint points, like ORMs (Django is
at the origin of this patch). The ODBC driver is a second layer that
likes a lot savepoints, though it does not use a random naming pattern.
A "location" field is added to TransactionStmt, now set only for
savepoints. The savepoint name is ignored by the query jumbling. The
location can be extended to other query patterns, if required, like 2PC
commands. Some tests are added to pg_stat_statements for all the query
patterns supported by the parser.
ROLLBACK, ROLLBACK TO SAVEPOINT and ROLLBACK TRANSACTION TO SAVEPOINT
have the same Node representation, so all these are equivalents. The
same happens for RELEASE and RELEASE SAVEPOINT.
Author: Greg Sabino Mullane
Discussion: https://postgr.es/m/CAKAnmm+2s9PA4OaumwMJReWHk8qvJ_-g1WqxDRDAN1BSUfxyTw@mail.gmail.com
2023-07-27 02:42:33 +02:00
|
|
|
1 | 0 | BEGIN
|
|
|
|
1 | 0 | COMMIT
|
|
|
|
3 | 0 | RELEASE $1
|
|
|
|
4 | 0 | ROLLBACK TO $1
|
|
|
|
4 | 0 | SAVEPOINT $1
|
2023-11-27 01:50:59 +01:00
|
|
|
1 | 1 | SELECT pg_stat_statements_reset() IS NOT NULL AS t
|
Show savepoint names as constants in pg_stat_statements
In pg_stat_statements, savepoint names now show up as constants with a
parameter symbol, using as base query string the one added as a new
entry to the PGSS hash table, leading to:
RELEASE $1
ROLLBACK TO $1
SAVEPOINT $1
Applying constants to these query parts is a huge advantage for
workloads that generate randomly savepoint points, like ORMs (Django is
at the origin of this patch). The ODBC driver is a second layer that
likes a lot savepoints, though it does not use a random naming pattern.
A "location" field is added to TransactionStmt, now set only for
savepoints. The savepoint name is ignored by the query jumbling. The
location can be extended to other query patterns, if required, like 2PC
commands. Some tests are added to pg_stat_statements for all the query
patterns supported by the parser.
ROLLBACK, ROLLBACK TO SAVEPOINT and ROLLBACK TRANSACTION TO SAVEPOINT
have the same Node representation, so all these are equivalents. The
same happens for RELEASE and RELEASE SAVEPOINT.
Author: Greg Sabino Mullane
Discussion: https://postgr.es/m/CAKAnmm+2s9PA4OaumwMJReWHk8qvJ_-g1WqxDRDAN1BSUfxyTw@mail.gmail.com
2023-07-27 02:42:33 +02:00
|
|
|
(6 rows)
|
|
|
|
|
2023-11-27 01:50:59 +01:00
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
t
|
|
|
|
---
|
|
|
|
t
|
Show savepoint names as constants in pg_stat_statements
In pg_stat_statements, savepoint names now show up as constants with a
parameter symbol, using as base query string the one added as a new
entry to the PGSS hash table, leading to:
RELEASE $1
ROLLBACK TO $1
SAVEPOINT $1
Applying constants to these query parts is a huge advantage for
workloads that generate randomly savepoint points, like ORMs (Django is
at the origin of this patch). The ODBC driver is a second layer that
likes a lot savepoints, though it does not use a random naming pattern.
A "location" field is added to TransactionStmt, now set only for
savepoints. The savepoint name is ignored by the query jumbling. The
location can be extended to other query patterns, if required, like 2PC
commands. Some tests are added to pg_stat_statements for all the query
patterns supported by the parser.
ROLLBACK, ROLLBACK TO SAVEPOINT and ROLLBACK TRANSACTION TO SAVEPOINT
have the same Node representation, so all these are equivalents. The
same happens for RELEASE and RELEASE SAVEPOINT.
Author: Greg Sabino Mullane
Discussion: https://postgr.es/m/CAKAnmm+2s9PA4OaumwMJReWHk8qvJ_-g1WqxDRDAN1BSUfxyTw@mail.gmail.com
2023-07-27 02:42:33 +02:00
|
|
|
(1 row)
|
|
|
|
|
Expand regression tests of pg_stat_statements for utility queries
This commit adds more coverage for utility statements so as it is
possible to track down all the effects of query normalization done for
all the queries that use either Const or A_Const nodes, which are the
nodes where normalization makes the most sense as they apply to
constants (well, most of the time, really).
This set of queries is extracted from an analysis done while looking at
full dumps of the regression database when applying different levels of
normalization to either Const or A_Const nodes for utilities, as of a
minimal set of these, for:
- All relkinds (CREATE, ALTER, DROP)
- Policies
- Cursors
- Triggers
- Types
- Rules
- Statistics
- CALL
- Transaction statements (isolation level, options)
- EXPLAIN
- COPY
Note that pg_stat_statements is not switched yet to show any
normalization for utilities, still it improves the default coverage of
the query jumbling code (not by as much as enabling query jumbling on
the main regression test suite, though):
- queryjumblefuncs.funcs.c: 36.8% => 48.5%
- queryjumblefuncs.switch.c: 33.2% => 43.1%
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 02:16:51 +01:00
|
|
|
-- EXPLAIN statements
|
|
|
|
-- A Query is used, normalized by the query jumbling.
|
|
|
|
EXPLAIN (costs off) SELECT 1;
|
|
|
|
QUERY PLAN
|
|
|
|
------------
|
|
|
|
Result
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
EXPLAIN (costs off) SELECT 2;
|
|
|
|
QUERY PLAN
|
|
|
|
------------
|
|
|
|
Result
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
EXPLAIN (costs off) SELECT a FROM generate_series(1,10) AS tab(a) WHERE a = 3;
|
|
|
|
QUERY PLAN
|
|
|
|
--------------------------------------
|
|
|
|
Function Scan on generate_series tab
|
|
|
|
Filter: (a = 3)
|
|
|
|
(2 rows)
|
|
|
|
|
|
|
|
EXPLAIN (costs off) SELECT a FROM generate_series(1,10) AS tab(a) WHERE a = 7;
|
|
|
|
QUERY PLAN
|
|
|
|
--------------------------------------
|
|
|
|
Function Scan on generate_series tab
|
|
|
|
Filter: (a = 7)
|
|
|
|
(2 rows)
|
|
|
|
|
|
|
|
SELECT calls, rows, query FROM pg_stat_statements ORDER BY query COLLATE "C";
|
2023-03-08 07:00:50 +01:00
|
|
|
calls | rows | query
|
|
|
|
-------+------+---------------------------------------------------------------------------------
|
|
|
|
2 | 0 | EXPLAIN (costs off) SELECT $1
|
|
|
|
2 | 0 | EXPLAIN (costs off) SELECT a FROM generate_series($1,$2) AS tab(a) WHERE a = $3
|
2023-11-27 01:50:59 +01:00
|
|
|
1 | 1 | SELECT pg_stat_statements_reset() IS NOT NULL AS t
|
Expand regression tests of pg_stat_statements for utility queries
This commit adds more coverage for utility statements so as it is
possible to track down all the effects of query normalization done for
all the queries that use either Const or A_Const nodes, which are the
nodes where normalization makes the most sense as they apply to
constants (well, most of the time, really).
This set of queries is extracted from an analysis done while looking at
full dumps of the regression database when applying different levels of
normalization to either Const or A_Const nodes for utilities, as of a
minimal set of these, for:
- All relkinds (CREATE, ALTER, DROP)
- Policies
- Cursors
- Triggers
- Types
- Rules
- Statistics
- CALL
- Transaction statements (isolation level, options)
- EXPLAIN
- COPY
Note that pg_stat_statements is not switched yet to show any
normalization for utilities, still it improves the default coverage of
the query jumbling code (not by as much as enabling query jumbling on
the main regression test suite, though):
- queryjumblefuncs.funcs.c: 36.8% => 48.5%
- queryjumblefuncs.switch.c: 33.2% => 43.1%
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 02:16:51 +01:00
|
|
|
(3 rows)
|
|
|
|
|
|
|
|
-- CALL
|
|
|
|
CREATE OR REPLACE PROCEDURE sum_one(i int) AS $$
|
|
|
|
DECLARE
|
|
|
|
r int;
|
|
|
|
BEGIN
|
|
|
|
SELECT (i + i)::int INTO r;
|
|
|
|
END; $$ LANGUAGE plpgsql;
|
|
|
|
CREATE OR REPLACE PROCEDURE sum_two(i int, j int) AS $$
|
|
|
|
DECLARE
|
|
|
|
r int;
|
|
|
|
BEGIN
|
|
|
|
SELECT (i + j)::int INTO r;
|
|
|
|
END; $$ LANGUAGE plpgsql;
|
2023-09-28 08:17:55 +02:00
|
|
|
-- Overloaded functions.
|
|
|
|
CREATE OR REPLACE PROCEDURE overload(i int) AS $$
|
|
|
|
DECLARE
|
|
|
|
r int;
|
|
|
|
BEGIN
|
|
|
|
SELECT (i + i)::int INTO r;
|
|
|
|
END; $$ LANGUAGE plpgsql;
|
|
|
|
CREATE OR REPLACE PROCEDURE overload(i text) AS $$
|
|
|
|
DECLARE
|
|
|
|
r text;
|
|
|
|
BEGIN
|
|
|
|
SELECT i::text INTO r;
|
|
|
|
END; $$ LANGUAGE plpgsql;
|
|
|
|
-- Mix of IN/OUT parameters.
|
|
|
|
CREATE OR REPLACE PROCEDURE in_out(i int, i2 OUT int, i3 INOUT int) AS $$
|
|
|
|
DECLARE
|
|
|
|
r int;
|
|
|
|
BEGIN
|
|
|
|
i2 := i;
|
|
|
|
i3 := i3 + i;
|
|
|
|
END; $$ LANGUAGE plpgsql;
|
2023-11-27 01:50:59 +01:00
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
t
|
|
|
|
---
|
|
|
|
t
|
Expand regression tests of pg_stat_statements for utility queries
This commit adds more coverage for utility statements so as it is
possible to track down all the effects of query normalization done for
all the queries that use either Const or A_Const nodes, which are the
nodes where normalization makes the most sense as they apply to
constants (well, most of the time, really).
This set of queries is extracted from an analysis done while looking at
full dumps of the regression database when applying different levels of
normalization to either Const or A_Const nodes for utilities, as of a
minimal set of these, for:
- All relkinds (CREATE, ALTER, DROP)
- Policies
- Cursors
- Triggers
- Types
- Rules
- Statistics
- CALL
- Transaction statements (isolation level, options)
- EXPLAIN
- COPY
Note that pg_stat_statements is not switched yet to show any
normalization for utilities, still it improves the default coverage of
the query jumbling code (not by as much as enabling query jumbling on
the main regression test suite, though):
- queryjumblefuncs.funcs.c: 36.8% => 48.5%
- queryjumblefuncs.switch.c: 33.2% => 43.1%
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 02:16:51 +01:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
CALL sum_one(3);
|
|
|
|
CALL sum_one(199);
|
|
|
|
CALL sum_two(1,1);
|
|
|
|
CALL sum_two(1,2);
|
2023-09-28 08:17:55 +02:00
|
|
|
CALL overload(1);
|
|
|
|
CALL overload('A');
|
|
|
|
CALL in_out(1, NULL, 1);
|
|
|
|
i2 | i3
|
|
|
|
----+----
|
|
|
|
1 | 2
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
CALL in_out(2, 1, 2);
|
|
|
|
i2 | i3
|
|
|
|
----+----
|
|
|
|
2 | 4
|
|
|
|
(1 row)
|
|
|
|
|
Expand regression tests of pg_stat_statements for utility queries
This commit adds more coverage for utility statements so as it is
possible to track down all the effects of query normalization done for
all the queries that use either Const or A_Const nodes, which are the
nodes where normalization makes the most sense as they apply to
constants (well, most of the time, really).
This set of queries is extracted from an analysis done while looking at
full dumps of the regression database when applying different levels of
normalization to either Const or A_Const nodes for utilities, as of a
minimal set of these, for:
- All relkinds (CREATE, ALTER, DROP)
- Policies
- Cursors
- Triggers
- Types
- Rules
- Statistics
- CALL
- Transaction statements (isolation level, options)
- EXPLAIN
- COPY
Note that pg_stat_statements is not switched yet to show any
normalization for utilities, still it improves the default coverage of
the query jumbling code (not by as much as enabling query jumbling on
the main regression test suite, though):
- queryjumblefuncs.funcs.c: 36.8% => 48.5%
- queryjumblefuncs.switch.c: 33.2% => 43.1%
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 02:16:51 +01:00
|
|
|
SELECT calls, rows, query FROM pg_stat_statements ORDER BY query COLLATE "C";
|
2023-11-27 01:50:59 +01:00
|
|
|
calls | rows | query
|
|
|
|
-------+------+----------------------------------------------------
|
2023-09-28 08:17:55 +02:00
|
|
|
2 | 0 | CALL in_out($1, $2, $3)
|
|
|
|
1 | 0 | CALL overload($1)
|
|
|
|
1 | 0 | CALL overload($1)
|
|
|
|
2 | 0 | CALL sum_one($1)
|
|
|
|
2 | 0 | CALL sum_two($1,$2)
|
2023-11-27 01:50:59 +01:00
|
|
|
1 | 1 | SELECT pg_stat_statements_reset() IS NOT NULL AS t
|
2023-09-28 08:17:55 +02:00
|
|
|
(6 rows)
|
Expand regression tests of pg_stat_statements for utility queries
This commit adds more coverage for utility statements so as it is
possible to track down all the effects of query normalization done for
all the queries that use either Const or A_Const nodes, which are the
nodes where normalization makes the most sense as they apply to
constants (well, most of the time, really).
This set of queries is extracted from an analysis done while looking at
full dumps of the regression database when applying different levels of
normalization to either Const or A_Const nodes for utilities, as of a
minimal set of these, for:
- All relkinds (CREATE, ALTER, DROP)
- Policies
- Cursors
- Triggers
- Types
- Rules
- Statistics
- CALL
- Transaction statements (isolation level, options)
- EXPLAIN
- COPY
Note that pg_stat_statements is not switched yet to show any
normalization for utilities, still it improves the default coverage of
the query jumbling code (not by as much as enabling query jumbling on
the main regression test suite, though):
- queryjumblefuncs.funcs.c: 36.8% => 48.5%
- queryjumblefuncs.switch.c: 33.2% => 43.1%
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 02:16:51 +01:00
|
|
|
|
|
|
|
-- COPY
|
|
|
|
CREATE TABLE copy_stats (a int, b int);
|
2023-11-27 01:50:59 +01:00
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
t
|
|
|
|
---
|
|
|
|
t
|
Expand regression tests of pg_stat_statements for utility queries
This commit adds more coverage for utility statements so as it is
possible to track down all the effects of query normalization done for
all the queries that use either Const or A_Const nodes, which are the
nodes where normalization makes the most sense as they apply to
constants (well, most of the time, really).
This set of queries is extracted from an analysis done while looking at
full dumps of the regression database when applying different levels of
normalization to either Const or A_Const nodes for utilities, as of a
minimal set of these, for:
- All relkinds (CREATE, ALTER, DROP)
- Policies
- Cursors
- Triggers
- Types
- Rules
- Statistics
- CALL
- Transaction statements (isolation level, options)
- EXPLAIN
- COPY
Note that pg_stat_statements is not switched yet to show any
normalization for utilities, still it improves the default coverage of
the query jumbling code (not by as much as enabling query jumbling on
the main regression test suite, though):
- queryjumblefuncs.funcs.c: 36.8% => 48.5%
- queryjumblefuncs.switch.c: 33.2% => 43.1%
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 02:16:51 +01:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- Some queries with A_Const nodes.
|
|
|
|
COPY (SELECT 1) TO STDOUT;
|
|
|
|
1
|
|
|
|
COPY (SELECT 2) TO STDOUT;
|
|
|
|
2
|
|
|
|
COPY (INSERT INTO copy_stats VALUES (1, 1) RETURNING *) TO STDOUT;
|
|
|
|
1 1
|
|
|
|
COPY (INSERT INTO copy_stats VALUES (2, 2) RETURNING *) TO STDOUT;
|
|
|
|
2 2
|
|
|
|
COPY (UPDATE copy_stats SET b = b + 1 RETURNING *) TO STDOUT;
|
|
|
|
1 2
|
|
|
|
2 3
|
|
|
|
COPY (UPDATE copy_stats SET b = b + 2 RETURNING *) TO STDOUT;
|
|
|
|
1 4
|
|
|
|
2 5
|
|
|
|
COPY (DELETE FROM copy_stats WHERE a = 1 RETURNING *) TO STDOUT;
|
|
|
|
1 4
|
|
|
|
SELECT calls, rows, query FROM pg_stat_statements ORDER BY query COLLATE "C";
|
|
|
|
calls | rows | query
|
|
|
|
-------+------+-------------------------------------------------------------------
|
|
|
|
1 | 1 | COPY (DELETE FROM copy_stats WHERE a = 1 RETURNING *) TO STDOUT
|
|
|
|
1 | 1 | COPY (INSERT INTO copy_stats VALUES (1, 1) RETURNING *) TO STDOUT
|
|
|
|
1 | 1 | COPY (INSERT INTO copy_stats VALUES (2, 2) RETURNING *) TO STDOUT
|
|
|
|
1 | 1 | COPY (SELECT 1) TO STDOUT
|
|
|
|
1 | 1 | COPY (SELECT 2) TO STDOUT
|
|
|
|
1 | 2 | COPY (UPDATE copy_stats SET b = b + 1 RETURNING *) TO STDOUT
|
|
|
|
1 | 2 | COPY (UPDATE copy_stats SET b = b + 2 RETURNING *) TO STDOUT
|
2023-11-27 01:50:59 +01:00
|
|
|
1 | 1 | SELECT pg_stat_statements_reset() IS NOT NULL AS t
|
Expand regression tests of pg_stat_statements for utility queries
This commit adds more coverage for utility statements so as it is
possible to track down all the effects of query normalization done for
all the queries that use either Const or A_Const nodes, which are the
nodes where normalization makes the most sense as they apply to
constants (well, most of the time, really).
This set of queries is extracted from an analysis done while looking at
full dumps of the regression database when applying different levels of
normalization to either Const or A_Const nodes for utilities, as of a
minimal set of these, for:
- All relkinds (CREATE, ALTER, DROP)
- Policies
- Cursors
- Triggers
- Types
- Rules
- Statistics
- CALL
- Transaction statements (isolation level, options)
- EXPLAIN
- COPY
Note that pg_stat_statements is not switched yet to show any
normalization for utilities, still it improves the default coverage of
the query jumbling code (not by as much as enabling query jumbling on
the main regression test suite, though):
- queryjumblefuncs.funcs.c: 36.8% => 48.5%
- queryjumblefuncs.switch.c: 33.2% => 43.1%
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 02:16:51 +01:00
|
|
|
(8 rows)
|
|
|
|
|
|
|
|
DROP TABLE copy_stats;
|
2023-11-27 01:50:59 +01:00
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
t
|
|
|
|
---
|
|
|
|
t
|
Expand regression tests of pg_stat_statements for utility queries
This commit adds more coverage for utility statements so as it is
possible to track down all the effects of query normalization done for
all the queries that use either Const or A_Const nodes, which are the
nodes where normalization makes the most sense as they apply to
constants (well, most of the time, really).
This set of queries is extracted from an analysis done while looking at
full dumps of the regression database when applying different levels of
normalization to either Const or A_Const nodes for utilities, as of a
minimal set of these, for:
- All relkinds (CREATE, ALTER, DROP)
- Policies
- Cursors
- Triggers
- Types
- Rules
- Statistics
- CALL
- Transaction statements (isolation level, options)
- EXPLAIN
- COPY
Note that pg_stat_statements is not switched yet to show any
normalization for utilities, still it improves the default coverage of
the query jumbling code (not by as much as enabling query jumbling on
the main regression test suite, though):
- queryjumblefuncs.funcs.c: 36.8% => 48.5%
- queryjumblefuncs.switch.c: 33.2% => 43.1%
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 02:16:51 +01:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- CREATE TABLE AS
|
|
|
|
-- SELECT queries are normalized, creating matching query IDs.
|
|
|
|
CREATE TABLE ctas_stats_1 AS SELECT 1 AS a;
|
|
|
|
DROP TABLE ctas_stats_1;
|
|
|
|
CREATE TABLE ctas_stats_1 AS SELECT 2 AS a;
|
|
|
|
DROP TABLE ctas_stats_1;
|
|
|
|
CREATE TABLE ctas_stats_2 AS
|
|
|
|
SELECT a AS col1, 2::int AS col2
|
|
|
|
FROM generate_series(1, 10) AS tab(a) WHERE a < 5 AND a > 2;
|
|
|
|
DROP TABLE ctas_stats_2;
|
|
|
|
CREATE TABLE ctas_stats_2 AS
|
|
|
|
SELECT a AS col1, 4::int AS col2
|
|
|
|
FROM generate_series(1, 5) AS tab(a) WHERE a < 4 AND a > 1;
|
|
|
|
DROP TABLE ctas_stats_2;
|
|
|
|
SELECT calls, rows, query FROM pg_stat_statements ORDER BY query COLLATE "C";
|
2023-03-08 07:00:50 +01:00
|
|
|
calls | rows | query
|
|
|
|
-------+------+--------------------------------------------------------------------
|
|
|
|
2 | 2 | CREATE TABLE ctas_stats_1 AS SELECT $1 AS a
|
|
|
|
2 | 4 | CREATE TABLE ctas_stats_2 AS +
|
|
|
|
| | SELECT a AS col1, $1::int AS col2 +
|
|
|
|
| | FROM generate_series($2, $3) AS tab(a) WHERE a < $4 AND a > $5
|
Expand regression tests of pg_stat_statements for utility queries
This commit adds more coverage for utility statements so as it is
possible to track down all the effects of query normalization done for
all the queries that use either Const or A_Const nodes, which are the
nodes where normalization makes the most sense as they apply to
constants (well, most of the time, really).
This set of queries is extracted from an analysis done while looking at
full dumps of the regression database when applying different levels of
normalization to either Const or A_Const nodes for utilities, as of a
minimal set of these, for:
- All relkinds (CREATE, ALTER, DROP)
- Policies
- Cursors
- Triggers
- Types
- Rules
- Statistics
- CALL
- Transaction statements (isolation level, options)
- EXPLAIN
- COPY
Note that pg_stat_statements is not switched yet to show any
normalization for utilities, still it improves the default coverage of
the query jumbling code (not by as much as enabling query jumbling on
the main regression test suite, though):
- queryjumblefuncs.funcs.c: 36.8% => 48.5%
- queryjumblefuncs.switch.c: 33.2% => 43.1%
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 02:16:51 +01:00
|
|
|
2 | 0 | DROP TABLE ctas_stats_1
|
|
|
|
2 | 0 | DROP TABLE ctas_stats_2
|
2023-11-27 01:50:59 +01:00
|
|
|
1 | 1 | SELECT pg_stat_statements_reset() IS NOT NULL AS t
|
Expand regression tests of pg_stat_statements for utility queries
This commit adds more coverage for utility statements so as it is
possible to track down all the effects of query normalization done for
all the queries that use either Const or A_Const nodes, which are the
nodes where normalization makes the most sense as they apply to
constants (well, most of the time, really).
This set of queries is extracted from an analysis done while looking at
full dumps of the regression database when applying different levels of
normalization to either Const or A_Const nodes for utilities, as of a
minimal set of these, for:
- All relkinds (CREATE, ALTER, DROP)
- Policies
- Cursors
- Triggers
- Types
- Rules
- Statistics
- CALL
- Transaction statements (isolation level, options)
- EXPLAIN
- COPY
Note that pg_stat_statements is not switched yet to show any
normalization for utilities, still it improves the default coverage of
the query jumbling code (not by as much as enabling query jumbling on
the main regression test suite, though):
- queryjumblefuncs.funcs.c: 36.8% => 48.5%
- queryjumblefuncs.switch.c: 33.2% => 43.1%
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 02:16:51 +01:00
|
|
|
(5 rows)
|
|
|
|
|
2023-11-27 01:50:59 +01:00
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
t
|
|
|
|
---
|
|
|
|
t
|
Expand regression tests of pg_stat_statements for utility queries
This commit adds more coverage for utility statements so as it is
possible to track down all the effects of query normalization done for
all the queries that use either Const or A_Const nodes, which are the
nodes where normalization makes the most sense as they apply to
constants (well, most of the time, really).
This set of queries is extracted from an analysis done while looking at
full dumps of the regression database when applying different levels of
normalization to either Const or A_Const nodes for utilities, as of a
minimal set of these, for:
- All relkinds (CREATE, ALTER, DROP)
- Policies
- Cursors
- Triggers
- Types
- Rules
- Statistics
- CALL
- Transaction statements (isolation level, options)
- EXPLAIN
- COPY
Note that pg_stat_statements is not switched yet to show any
normalization for utilities, still it improves the default coverage of
the query jumbling code (not by as much as enabling query jumbling on
the main regression test suite, though):
- queryjumblefuncs.funcs.c: 36.8% => 48.5%
- queryjumblefuncs.switch.c: 33.2% => 43.1%
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 02:16:51 +01:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- CREATE MATERIALIZED VIEW
|
|
|
|
-- SELECT queries are normalized, creating matching query IDs.
|
|
|
|
CREATE MATERIALIZED VIEW matview_stats_1 AS
|
|
|
|
SELECT a AS col1, 2::int AS col2
|
|
|
|
FROM generate_series(1, 10) AS tab(a) WHERE a < 5 AND a > 2;
|
|
|
|
DROP MATERIALIZED VIEW matview_stats_1;
|
|
|
|
CREATE MATERIALIZED VIEW matview_stats_1 AS
|
|
|
|
SELECT a AS col1, 4::int AS col2
|
|
|
|
FROM generate_series(1, 5) AS tab(a) WHERE a < 4 AND a > 3;
|
|
|
|
DROP MATERIALIZED VIEW matview_stats_1;
|
|
|
|
SELECT calls, rows, query FROM pg_stat_statements ORDER BY query COLLATE "C";
|
2023-03-08 07:00:50 +01:00
|
|
|
calls | rows | query
|
|
|
|
-------+------+--------------------------------------------------------------------
|
|
|
|
2 | 2 | CREATE MATERIALIZED VIEW matview_stats_1 AS +
|
|
|
|
| | SELECT a AS col1, $1::int AS col2 +
|
|
|
|
| | FROM generate_series($2, $3) AS tab(a) WHERE a < $4 AND a > $5
|
Expand regression tests of pg_stat_statements for utility queries
This commit adds more coverage for utility statements so as it is
possible to track down all the effects of query normalization done for
all the queries that use either Const or A_Const nodes, which are the
nodes where normalization makes the most sense as they apply to
constants (well, most of the time, really).
This set of queries is extracted from an analysis done while looking at
full dumps of the regression database when applying different levels of
normalization to either Const or A_Const nodes for utilities, as of a
minimal set of these, for:
- All relkinds (CREATE, ALTER, DROP)
- Policies
- Cursors
- Triggers
- Types
- Rules
- Statistics
- CALL
- Transaction statements (isolation level, options)
- EXPLAIN
- COPY
Note that pg_stat_statements is not switched yet to show any
normalization for utilities, still it improves the default coverage of
the query jumbling code (not by as much as enabling query jumbling on
the main regression test suite, though):
- queryjumblefuncs.funcs.c: 36.8% => 48.5%
- queryjumblefuncs.switch.c: 33.2% => 43.1%
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 02:16:51 +01:00
|
|
|
2 | 0 | DROP MATERIALIZED VIEW matview_stats_1
|
2023-11-27 01:50:59 +01:00
|
|
|
1 | 1 | SELECT pg_stat_statements_reset() IS NOT NULL AS t
|
Expand regression tests of pg_stat_statements for utility queries
This commit adds more coverage for utility statements so as it is
possible to track down all the effects of query normalization done for
all the queries that use either Const or A_Const nodes, which are the
nodes where normalization makes the most sense as they apply to
constants (well, most of the time, really).
This set of queries is extracted from an analysis done while looking at
full dumps of the regression database when applying different levels of
normalization to either Const or A_Const nodes for utilities, as of a
minimal set of these, for:
- All relkinds (CREATE, ALTER, DROP)
- Policies
- Cursors
- Triggers
- Types
- Rules
- Statistics
- CALL
- Transaction statements (isolation level, options)
- EXPLAIN
- COPY
Note that pg_stat_statements is not switched yet to show any
normalization for utilities, still it improves the default coverage of
the query jumbling code (not by as much as enabling query jumbling on
the main regression test suite, though):
- queryjumblefuncs.funcs.c: 36.8% => 48.5%
- queryjumblefuncs.switch.c: 33.2% => 43.1%
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 02:16:51 +01:00
|
|
|
(3 rows)
|
|
|
|
|
2023-11-27 01:50:59 +01:00
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
t
|
|
|
|
---
|
|
|
|
t
|
Expand regression tests of pg_stat_statements for utility queries
This commit adds more coverage for utility statements so as it is
possible to track down all the effects of query normalization done for
all the queries that use either Const or A_Const nodes, which are the
nodes where normalization makes the most sense as they apply to
constants (well, most of the time, really).
This set of queries is extracted from an analysis done while looking at
full dumps of the regression database when applying different levels of
normalization to either Const or A_Const nodes for utilities, as of a
minimal set of these, for:
- All relkinds (CREATE, ALTER, DROP)
- Policies
- Cursors
- Triggers
- Types
- Rules
- Statistics
- CALL
- Transaction statements (isolation level, options)
- EXPLAIN
- COPY
Note that pg_stat_statements is not switched yet to show any
normalization for utilities, still it improves the default coverage of
the query jumbling code (not by as much as enabling query jumbling on
the main regression test suite, though):
- queryjumblefuncs.funcs.c: 36.8% => 48.5%
- queryjumblefuncs.switch.c: 33.2% => 43.1%
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 02:16:51 +01:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- CREATE VIEW
|
|
|
|
CREATE VIEW view_stats_1 AS
|
|
|
|
SELECT a AS col1, 2::int AS col2
|
|
|
|
FROM generate_series(1, 10) AS tab(a) WHERE a < 5 AND a > 2;
|
|
|
|
DROP VIEW view_stats_1;
|
|
|
|
CREATE VIEW view_stats_1 AS
|
|
|
|
SELECT a AS col1, 4::int AS col2
|
|
|
|
FROM generate_series(1, 5) AS tab(a) WHERE a < 4 AND a > 3;
|
|
|
|
DROP VIEW view_stats_1;
|
|
|
|
SELECT calls, rows, query FROM pg_stat_statements ORDER BY query COLLATE "C";
|
|
|
|
calls | rows | query
|
|
|
|
-------+------+-----------------------------------------------------------------
|
|
|
|
1 | 0 | CREATE VIEW view_stats_1 AS +
|
|
|
|
| | SELECT a AS col1, 2::int AS col2 +
|
|
|
|
| | FROM generate_series(1, 10) AS tab(a) WHERE a < 5 AND a > 2
|
|
|
|
1 | 0 | CREATE VIEW view_stats_1 AS +
|
|
|
|
| | SELECT a AS col1, 4::int AS col2 +
|
|
|
|
| | FROM generate_series(1, 5) AS tab(a) WHERE a < 4 AND a > 3
|
|
|
|
2 | 0 | DROP VIEW view_stats_1
|
2023-11-27 01:50:59 +01:00
|
|
|
1 | 1 | SELECT pg_stat_statements_reset() IS NOT NULL AS t
|
Expand regression tests of pg_stat_statements for utility queries
This commit adds more coverage for utility statements so as it is
possible to track down all the effects of query normalization done for
all the queries that use either Const or A_Const nodes, which are the
nodes where normalization makes the most sense as they apply to
constants (well, most of the time, really).
This set of queries is extracted from an analysis done while looking at
full dumps of the regression database when applying different levels of
normalization to either Const or A_Const nodes for utilities, as of a
minimal set of these, for:
- All relkinds (CREATE, ALTER, DROP)
- Policies
- Cursors
- Triggers
- Types
- Rules
- Statistics
- CALL
- Transaction statements (isolation level, options)
- EXPLAIN
- COPY
Note that pg_stat_statements is not switched yet to show any
normalization for utilities, still it improves the default coverage of
the query jumbling code (not by as much as enabling query jumbling on
the main regression test suite, though):
- queryjumblefuncs.funcs.c: 36.8% => 48.5%
- queryjumblefuncs.switch.c: 33.2% => 43.1%
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 02:16:51 +01:00
|
|
|
(4 rows)
|
|
|
|
|
2023-11-27 01:50:59 +01:00
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
t
|
|
|
|
---
|
|
|
|
t
|
Expand regression tests of pg_stat_statements for utility queries
This commit adds more coverage for utility statements so as it is
possible to track down all the effects of query normalization done for
all the queries that use either Const or A_Const nodes, which are the
nodes where normalization makes the most sense as they apply to
constants (well, most of the time, really).
This set of queries is extracted from an analysis done while looking at
full dumps of the regression database when applying different levels of
normalization to either Const or A_Const nodes for utilities, as of a
minimal set of these, for:
- All relkinds (CREATE, ALTER, DROP)
- Policies
- Cursors
- Triggers
- Types
- Rules
- Statistics
- CALL
- Transaction statements (isolation level, options)
- EXPLAIN
- COPY
Note that pg_stat_statements is not switched yet to show any
normalization for utilities, still it improves the default coverage of
the query jumbling code (not by as much as enabling query jumbling on
the main regression test suite, though):
- queryjumblefuncs.funcs.c: 36.8% => 48.5%
- queryjumblefuncs.switch.c: 33.2% => 43.1%
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 02:16:51 +01:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
-- Domains
|
|
|
|
CREATE DOMAIN domain_stats AS int CHECK (VALUE > 0);
|
|
|
|
ALTER DOMAIN domain_stats SET DEFAULT '3';
|
|
|
|
ALTER DOMAIN domain_stats ADD CONSTRAINT higher_than_one CHECK (VALUE > 1);
|
|
|
|
DROP DOMAIN domain_stats;
|
|
|
|
SELECT calls, rows, query FROM pg_stat_statements ORDER BY query COLLATE "C";
|
|
|
|
calls | rows | query
|
|
|
|
-------+------+----------------------------------------------------------------------------
|
|
|
|
1 | 0 | ALTER DOMAIN domain_stats ADD CONSTRAINT higher_than_one CHECK (VALUE > 1)
|
|
|
|
1 | 0 | ALTER DOMAIN domain_stats SET DEFAULT '3'
|
|
|
|
1 | 0 | CREATE DOMAIN domain_stats AS int CHECK (VALUE > 0)
|
|
|
|
1 | 0 | DROP DOMAIN domain_stats
|
2023-11-27 01:50:59 +01:00
|
|
|
1 | 1 | SELECT pg_stat_statements_reset() IS NOT NULL AS t
|
Expand regression tests of pg_stat_statements for utility queries
This commit adds more coverage for utility statements so as it is
possible to track down all the effects of query normalization done for
all the queries that use either Const or A_Const nodes, which are the
nodes where normalization makes the most sense as they apply to
constants (well, most of the time, really).
This set of queries is extracted from an analysis done while looking at
full dumps of the regression database when applying different levels of
normalization to either Const or A_Const nodes for utilities, as of a
minimal set of these, for:
- All relkinds (CREATE, ALTER, DROP)
- Policies
- Cursors
- Triggers
- Types
- Rules
- Statistics
- CALL
- Transaction statements (isolation level, options)
- EXPLAIN
- COPY
Note that pg_stat_statements is not switched yet to show any
normalization for utilities, still it improves the default coverage of
the query jumbling code (not by as much as enabling query jumbling on
the main regression test suite, though):
- queryjumblefuncs.funcs.c: 36.8% => 48.5%
- queryjumblefuncs.switch.c: 33.2% => 43.1%
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 02:16:51 +01:00
|
|
|
(5 rows)
|
|
|
|
|
2023-11-27 01:50:59 +01:00
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
t
|
|
|
|
---
|
|
|
|
t
|
Expand regression tests of pg_stat_statements for utility queries
This commit adds more coverage for utility statements so as it is
possible to track down all the effects of query normalization done for
all the queries that use either Const or A_Const nodes, which are the
nodes where normalization makes the most sense as they apply to
constants (well, most of the time, really).
This set of queries is extracted from an analysis done while looking at
full dumps of the regression database when applying different levels of
normalization to either Const or A_Const nodes for utilities, as of a
minimal set of these, for:
- All relkinds (CREATE, ALTER, DROP)
- Policies
- Cursors
- Triggers
- Types
- Rules
- Statistics
- CALL
- Transaction statements (isolation level, options)
- EXPLAIN
- COPY
Note that pg_stat_statements is not switched yet to show any
normalization for utilities, still it improves the default coverage of
the query jumbling code (not by as much as enabling query jumbling on
the main regression test suite, though):
- queryjumblefuncs.funcs.c: 36.8% => 48.5%
- queryjumblefuncs.switch.c: 33.2% => 43.1%
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 02:16:51 +01:00
|
|
|
(1 row)
|
|
|
|
|
2023-08-27 10:27:44 +02:00
|
|
|
-- Execution statements
|
|
|
|
SELECT 1 as a;
|
|
|
|
a
|
|
|
|
---
|
|
|
|
1
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
PREPARE stat_select AS SELECT $1 AS a;
|
|
|
|
EXECUTE stat_select (1);
|
|
|
|
a
|
|
|
|
---
|
|
|
|
1
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
DEALLOCATE stat_select;
|
|
|
|
PREPARE stat_select AS SELECT $1 AS a;
|
|
|
|
EXECUTE stat_select (2);
|
|
|
|
a
|
|
|
|
---
|
|
|
|
2
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
DEALLOCATE PREPARE stat_select;
|
|
|
|
DEALLOCATE ALL;
|
|
|
|
DEALLOCATE PREPARE ALL;
|
|
|
|
SELECT calls, rows, query FROM pg_stat_statements ORDER BY query COLLATE "C";
|
2023-11-27 01:50:59 +01:00
|
|
|
calls | rows | query
|
|
|
|
-------+------+----------------------------------------------------
|
2023-08-27 10:27:44 +02:00
|
|
|
2 | 0 | DEALLOCATE $1
|
|
|
|
2 | 0 | DEALLOCATE ALL
|
|
|
|
2 | 2 | PREPARE stat_select AS SELECT $1 AS a
|
|
|
|
1 | 1 | SELECT $1 as a
|
2023-11-27 01:50:59 +01:00
|
|
|
1 | 1 | SELECT pg_stat_statements_reset() IS NOT NULL AS t
|
2023-08-27 10:27:44 +02:00
|
|
|
(5 rows)
|
|
|
|
|
2023-11-27 01:50:59 +01:00
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
t
|
|
|
|
---
|
|
|
|
t
|
2023-08-27 10:27:44 +02:00
|
|
|
(1 row)
|
|
|
|
|
Expand regression tests of pg_stat_statements for utility queries
This commit adds more coverage for utility statements so as it is
possible to track down all the effects of query normalization done for
all the queries that use either Const or A_Const nodes, which are the
nodes where normalization makes the most sense as they apply to
constants (well, most of the time, really).
This set of queries is extracted from an analysis done while looking at
full dumps of the regression database when applying different levels of
normalization to either Const or A_Const nodes for utilities, as of a
minimal set of these, for:
- All relkinds (CREATE, ALTER, DROP)
- Policies
- Cursors
- Triggers
- Types
- Rules
- Statistics
- CALL
- Transaction statements (isolation level, options)
- EXPLAIN
- COPY
Note that pg_stat_statements is not switched yet to show any
normalization for utilities, still it improves the default coverage of
the query jumbling code (not by as much as enabling query jumbling on
the main regression test suite, though):
- queryjumblefuncs.funcs.c: 36.8% => 48.5%
- queryjumblefuncs.switch.c: 33.2% => 43.1%
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 02:16:51 +01:00
|
|
|
-- SET statements.
|
|
|
|
-- These use two different strings, still they count as one entry.
|
|
|
|
SET work_mem = '1MB';
|
|
|
|
Set work_mem = '1MB';
|
|
|
|
SET work_mem = '2MB';
|
|
|
|
RESET work_mem;
|
|
|
|
SET enable_seqscan = off;
|
|
|
|
SET enable_seqscan = on;
|
|
|
|
RESET enable_seqscan;
|
|
|
|
-- SET TRANSACTION ISOLATION
|
|
|
|
BEGIN;
|
|
|
|
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
|
|
|
|
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
|
|
|
|
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
|
|
|
|
COMMIT;
|
|
|
|
-- SET SESSION CHARACTERISTICS
|
|
|
|
SET SESSION SESSION AUTHORIZATION DEFAULT;
|
|
|
|
RESET SESSION AUTHORIZATION;
|
|
|
|
BEGIN;
|
|
|
|
SET LOCAL SESSION AUTHORIZATION DEFAULT;
|
|
|
|
RESET SESSION AUTHORIZATION;
|
|
|
|
COMMIT;
|
|
|
|
SELECT calls, rows, query FROM pg_stat_statements ORDER BY query COLLATE "C";
|
2023-11-27 01:50:59 +01:00
|
|
|
calls | rows | query
|
|
|
|
-------+------+----------------------------------------------------
|
Expand regression tests of pg_stat_statements for utility queries
This commit adds more coverage for utility statements so as it is
possible to track down all the effects of query normalization done for
all the queries that use either Const or A_Const nodes, which are the
nodes where normalization makes the most sense as they apply to
constants (well, most of the time, really).
This set of queries is extracted from an analysis done while looking at
full dumps of the regression database when applying different levels of
normalization to either Const or A_Const nodes for utilities, as of a
minimal set of these, for:
- All relkinds (CREATE, ALTER, DROP)
- Policies
- Cursors
- Triggers
- Types
- Rules
- Statistics
- CALL
- Transaction statements (isolation level, options)
- EXPLAIN
- COPY
Note that pg_stat_statements is not switched yet to show any
normalization for utilities, still it improves the default coverage of
the query jumbling code (not by as much as enabling query jumbling on
the main regression test suite, though):
- queryjumblefuncs.funcs.c: 36.8% => 48.5%
- queryjumblefuncs.switch.c: 33.2% => 43.1%
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 02:16:51 +01:00
|
|
|
2 | 0 | BEGIN
|
|
|
|
2 | 0 | COMMIT
|
|
|
|
2 | 0 | RESET SESSION AUTHORIZATION
|
|
|
|
1 | 0 | RESET enable_seqscan
|
|
|
|
1 | 0 | RESET work_mem
|
2023-11-27 01:50:59 +01:00
|
|
|
1 | 1 | SELECT pg_stat_statements_reset() IS NOT NULL AS t
|
Expand regression tests of pg_stat_statements for utility queries
This commit adds more coverage for utility statements so as it is
possible to track down all the effects of query normalization done for
all the queries that use either Const or A_Const nodes, which are the
nodes where normalization makes the most sense as they apply to
constants (well, most of the time, really).
This set of queries is extracted from an analysis done while looking at
full dumps of the regression database when applying different levels of
normalization to either Const or A_Const nodes for utilities, as of a
minimal set of these, for:
- All relkinds (CREATE, ALTER, DROP)
- Policies
- Cursors
- Triggers
- Types
- Rules
- Statistics
- CALL
- Transaction statements (isolation level, options)
- EXPLAIN
- COPY
Note that pg_stat_statements is not switched yet to show any
normalization for utilities, still it improves the default coverage of
the query jumbling code (not by as much as enabling query jumbling on
the main regression test suite, though):
- queryjumblefuncs.funcs.c: 36.8% => 48.5%
- queryjumblefuncs.switch.c: 33.2% => 43.1%
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 02:16:51 +01:00
|
|
|
1 | 0 | SET LOCAL SESSION AUTHORIZATION DEFAULT
|
|
|
|
1 | 0 | SET SESSION SESSION AUTHORIZATION DEFAULT
|
|
|
|
1 | 0 | SET TRANSACTION ISOLATION LEVEL READ COMMITTED
|
|
|
|
1 | 0 | SET TRANSACTION ISOLATION LEVEL REPEATABLE READ
|
|
|
|
1 | 0 | SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
|
|
|
|
1 | 0 | SET enable_seqscan = off
|
|
|
|
1 | 0 | SET enable_seqscan = on
|
|
|
|
2 | 0 | SET work_mem = '1MB'
|
|
|
|
1 | 0 | SET work_mem = '2MB'
|
|
|
|
(15 rows)
|
Refactor tests of pg_stat_statements for planning, utility and level tracking
pg_stat_statements.sql acts as the main file for all the core tests of
the module, but things have become complicated to follow over the years
as some of the sub-scenarios tested in this file rely on assumptions
that come from completely different areas of it, like a GUC setup or a
relation created previously. For example, row tracking for CTAS/COPY
was looking at the number of plans, which was not necessary, or level
tracking was mixed with checks on planner counts.
This commit refactors the tests of pg_stat_statements, by moving test
cases out of pg_stat_statements.sql into their own file, as of:
- Planning-related tests in planning.sql, for [re]plan counts and
top-level handling. These depend on pg_stat_statements.track_planning.
- Utilities in utility.sql (pg_stat_statements.track_utility), that
includes now the tests for:
-- Row tracking for CTAS, CREATE MATERIALIZED VIEW, COPY.
-- Basic utility statements.
-- SET statements.
- Tracking level, depending on pg_stat_statements.track. This part has
been looking at scenarios with DO blocks, PL functions and SQL
functions.
pg_stat_statements.sql (still named the same for now) still includes
some checks for role-level tracking and WAL generation metrics, that
ought to become independent in the long term for clarity.
While on it, this switches the order of the attributes when querying
pg_stat_statements, the query field becoming last. This makes much
easier the tracking of changes related to normalization, as queries are
the only variable-length attributes queried (unaligned mode would be one
extra choice, but that reduces the checks on the other fields).
Test scenarios and their results match exactly with what was happening
before this commit in terms of calls, number of plans, number of rows,
cached data or level tracking, so this has no effect on the coverage in
terms of what is produced by the reports in the table
pg_stat_statements. A follow-up patch will extend more the tests of
pg_stat_statements around utilities, so this split creates a foundation
for this purpose, without complicating more pg_stat_statements.sql.
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 01:28:29 +01:00
|
|
|
|
2023-11-27 01:50:59 +01:00
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
t
|
|
|
|
---
|
|
|
|
t
|
Refactor tests of pg_stat_statements for planning, utility and level tracking
pg_stat_statements.sql acts as the main file for all the core tests of
the module, but things have become complicated to follow over the years
as some of the sub-scenarios tested in this file rely on assumptions
that come from completely different areas of it, like a GUC setup or a
relation created previously. For example, row tracking for CTAS/COPY
was looking at the number of plans, which was not necessary, or level
tracking was mixed with checks on planner counts.
This commit refactors the tests of pg_stat_statements, by moving test
cases out of pg_stat_statements.sql into their own file, as of:
- Planning-related tests in planning.sql, for [re]plan counts and
top-level handling. These depend on pg_stat_statements.track_planning.
- Utilities in utility.sql (pg_stat_statements.track_utility), that
includes now the tests for:
-- Row tracking for CTAS, CREATE MATERIALIZED VIEW, COPY.
-- Basic utility statements.
-- SET statements.
- Tracking level, depending on pg_stat_statements.track. This part has
been looking at scenarios with DO blocks, PL functions and SQL
functions.
pg_stat_statements.sql (still named the same for now) still includes
some checks for role-level tracking and WAL generation metrics, that
ought to become independent in the long term for clarity.
While on it, this switches the order of the attributes when querying
pg_stat_statements, the query field becoming last. This makes much
easier the tracking of changes related to normalization, as queries are
the only variable-length attributes queried (unaligned mode would be one
extra choice, but that reduces the checks on the other fields).
Test scenarios and their results match exactly with what was happening
before this commit in terms of calls, number of plans, number of rows,
cached data or level tracking, so this has no effect on the coverage in
terms of what is produced by the reports in the table
pg_stat_statements. A follow-up patch will extend more the tests of
pg_stat_statements around utilities, so this split creates a foundation
for this purpose, without complicating more pg_stat_statements.sql.
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 01:28:29 +01:00
|
|
|
(1 row)
|
|
|
|
|
|
|
|
--
|
|
|
|
-- Track the total number of rows retrieved or affected by the utility
|
|
|
|
-- commands of COPY, FETCH, CREATE TABLE AS, CREATE MATERIALIZED VIEW,
|
|
|
|
-- REFRESH MATERIALIZED VIEW and SELECT INTO
|
|
|
|
--
|
|
|
|
CREATE TABLE pgss_ctas AS SELECT a, 'ctas' b FROM generate_series(1, 10) a;
|
|
|
|
SELECT generate_series(1, 10) c INTO pgss_select_into;
|
|
|
|
COPY pgss_ctas (a, b) FROM STDIN;
|
|
|
|
CREATE MATERIALIZED VIEW pgss_matv AS SELECT * FROM pgss_ctas;
|
|
|
|
REFRESH MATERIALIZED VIEW pgss_matv;
|
|
|
|
BEGIN;
|
|
|
|
DECLARE pgss_cursor CURSOR FOR SELECT * FROM pgss_matv;
|
|
|
|
FETCH NEXT pgss_cursor;
|
|
|
|
a | b
|
|
|
|
---+------
|
|
|
|
1 | ctas
|
|
|
|
(1 row)
|
|
|
|
|
|
|
|
FETCH FORWARD 5 pgss_cursor;
|
|
|
|
a | b
|
|
|
|
---+------
|
|
|
|
2 | ctas
|
|
|
|
3 | ctas
|
|
|
|
4 | ctas
|
|
|
|
5 | ctas
|
|
|
|
6 | ctas
|
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
FETCH FORWARD ALL pgss_cursor;
|
|
|
|
a | b
|
|
|
|
----+------
|
|
|
|
7 | ctas
|
|
|
|
8 | ctas
|
|
|
|
9 | ctas
|
|
|
|
10 | ctas
|
|
|
|
11 | copy
|
|
|
|
12 | copy
|
|
|
|
13 | copy
|
|
|
|
(7 rows)
|
|
|
|
|
|
|
|
COMMIT;
|
|
|
|
SELECT calls, rows, query FROM pg_stat_statements ORDER BY query COLLATE "C";
|
2023-03-08 07:00:50 +01:00
|
|
|
calls | rows | query
|
|
|
|
-------+------+-------------------------------------------------------------------------
|
Refactor tests of pg_stat_statements for planning, utility and level tracking
pg_stat_statements.sql acts as the main file for all the core tests of
the module, but things have become complicated to follow over the years
as some of the sub-scenarios tested in this file rely on assumptions
that come from completely different areas of it, like a GUC setup or a
relation created previously. For example, row tracking for CTAS/COPY
was looking at the number of plans, which was not necessary, or level
tracking was mixed with checks on planner counts.
This commit refactors the tests of pg_stat_statements, by moving test
cases out of pg_stat_statements.sql into their own file, as of:
- Planning-related tests in planning.sql, for [re]plan counts and
top-level handling. These depend on pg_stat_statements.track_planning.
- Utilities in utility.sql (pg_stat_statements.track_utility), that
includes now the tests for:
-- Row tracking for CTAS, CREATE MATERIALIZED VIEW, COPY.
-- Basic utility statements.
-- SET statements.
- Tracking level, depending on pg_stat_statements.track. This part has
been looking at scenarios with DO blocks, PL functions and SQL
functions.
pg_stat_statements.sql (still named the same for now) still includes
some checks for role-level tracking and WAL generation metrics, that
ought to become independent in the long term for clarity.
While on it, this switches the order of the attributes when querying
pg_stat_statements, the query field becoming last. This makes much
easier the tracking of changes related to normalization, as queries are
the only variable-length attributes queried (unaligned mode would be one
extra choice, but that reduces the checks on the other fields).
Test scenarios and their results match exactly with what was happening
before this commit in terms of calls, number of plans, number of rows,
cached data or level tracking, so this has no effect on the coverage in
terms of what is produced by the reports in the table
pg_stat_statements. A follow-up patch will extend more the tests of
pg_stat_statements around utilities, so this split creates a foundation
for this purpose, without complicating more pg_stat_statements.sql.
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 01:28:29 +01:00
|
|
|
1 | 0 | BEGIN
|
|
|
|
1 | 0 | COMMIT
|
|
|
|
1 | 3 | COPY pgss_ctas (a, b) FROM STDIN
|
|
|
|
1 | 13 | CREATE MATERIALIZED VIEW pgss_matv AS SELECT * FROM pgss_ctas
|
2023-03-08 07:00:50 +01:00
|
|
|
1 | 10 | CREATE TABLE pgss_ctas AS SELECT a, $1 b FROM generate_series($2, $3) a
|
Refactor tests of pg_stat_statements for planning, utility and level tracking
pg_stat_statements.sql acts as the main file for all the core tests of
the module, but things have become complicated to follow over the years
as some of the sub-scenarios tested in this file rely on assumptions
that come from completely different areas of it, like a GUC setup or a
relation created previously. For example, row tracking for CTAS/COPY
was looking at the number of plans, which was not necessary, or level
tracking was mixed with checks on planner counts.
This commit refactors the tests of pg_stat_statements, by moving test
cases out of pg_stat_statements.sql into their own file, as of:
- Planning-related tests in planning.sql, for [re]plan counts and
top-level handling. These depend on pg_stat_statements.track_planning.
- Utilities in utility.sql (pg_stat_statements.track_utility), that
includes now the tests for:
-- Row tracking for CTAS, CREATE MATERIALIZED VIEW, COPY.
-- Basic utility statements.
-- SET statements.
- Tracking level, depending on pg_stat_statements.track. This part has
been looking at scenarios with DO blocks, PL functions and SQL
functions.
pg_stat_statements.sql (still named the same for now) still includes
some checks for role-level tracking and WAL generation metrics, that
ought to become independent in the long term for clarity.
While on it, this switches the order of the attributes when querying
pg_stat_statements, the query field becoming last. This makes much
easier the tracking of changes related to normalization, as queries are
the only variable-length attributes queried (unaligned mode would be one
extra choice, but that reduces the checks on the other fields).
Test scenarios and their results match exactly with what was happening
before this commit in terms of calls, number of plans, number of rows,
cached data or level tracking, so this has no effect on the coverage in
terms of what is produced by the reports in the table
pg_stat_statements. A follow-up patch will extend more the tests of
pg_stat_statements around utilities, so this split creates a foundation
for this purpose, without complicating more pg_stat_statements.sql.
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 01:28:29 +01:00
|
|
|
1 | 0 | DECLARE pgss_cursor CURSOR FOR SELECT * FROM pgss_matv
|
|
|
|
1 | 5 | FETCH FORWARD 5 pgss_cursor
|
|
|
|
1 | 7 | FETCH FORWARD ALL pgss_cursor
|
|
|
|
1 | 1 | FETCH NEXT pgss_cursor
|
|
|
|
1 | 13 | REFRESH MATERIALIZED VIEW pgss_matv
|
2023-03-08 07:00:50 +01:00
|
|
|
1 | 10 | SELECT generate_series($1, $2) c INTO pgss_select_into
|
2023-11-27 01:50:59 +01:00
|
|
|
1 | 1 | SELECT pg_stat_statements_reset() IS NOT NULL AS t
|
Refactor tests of pg_stat_statements for planning, utility and level tracking
pg_stat_statements.sql acts as the main file for all the core tests of
the module, but things have become complicated to follow over the years
as some of the sub-scenarios tested in this file rely on assumptions
that come from completely different areas of it, like a GUC setup or a
relation created previously. For example, row tracking for CTAS/COPY
was looking at the number of plans, which was not necessary, or level
tracking was mixed with checks on planner counts.
This commit refactors the tests of pg_stat_statements, by moving test
cases out of pg_stat_statements.sql into their own file, as of:
- Planning-related tests in planning.sql, for [re]plan counts and
top-level handling. These depend on pg_stat_statements.track_planning.
- Utilities in utility.sql (pg_stat_statements.track_utility), that
includes now the tests for:
-- Row tracking for CTAS, CREATE MATERIALIZED VIEW, COPY.
-- Basic utility statements.
-- SET statements.
- Tracking level, depending on pg_stat_statements.track. This part has
been looking at scenarios with DO blocks, PL functions and SQL
functions.
pg_stat_statements.sql (still named the same for now) still includes
some checks for role-level tracking and WAL generation metrics, that
ought to become independent in the long term for clarity.
While on it, this switches the order of the attributes when querying
pg_stat_statements, the query field becoming last. This makes much
easier the tracking of changes related to normalization, as queries are
the only variable-length attributes queried (unaligned mode would be one
extra choice, but that reduces the checks on the other fields).
Test scenarios and their results match exactly with what was happening
before this commit in terms of calls, number of plans, number of rows,
cached data or level tracking, so this has no effect on the coverage in
terms of what is produced by the reports in the table
pg_stat_statements. A follow-up patch will extend more the tests of
pg_stat_statements around utilities, so this split creates a foundation
for this purpose, without complicating more pg_stat_statements.sql.
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 01:28:29 +01:00
|
|
|
(12 rows)
|
|
|
|
|
|
|
|
DROP MATERIALIZED VIEW pgss_matv;
|
|
|
|
DROP TABLE pgss_ctas;
|
|
|
|
DROP TABLE pgss_select_into;
|
2023-11-27 01:50:59 +01:00
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
t
|
|
|
|
---
|
|
|
|
t
|
Refactor tests of pg_stat_statements for planning, utility and level tracking
pg_stat_statements.sql acts as the main file for all the core tests of
the module, but things have become complicated to follow over the years
as some of the sub-scenarios tested in this file rely on assumptions
that come from completely different areas of it, like a GUC setup or a
relation created previously. For example, row tracking for CTAS/COPY
was looking at the number of plans, which was not necessary, or level
tracking was mixed with checks on planner counts.
This commit refactors the tests of pg_stat_statements, by moving test
cases out of pg_stat_statements.sql into their own file, as of:
- Planning-related tests in planning.sql, for [re]plan counts and
top-level handling. These depend on pg_stat_statements.track_planning.
- Utilities in utility.sql (pg_stat_statements.track_utility), that
includes now the tests for:
-- Row tracking for CTAS, CREATE MATERIALIZED VIEW, COPY.
-- Basic utility statements.
-- SET statements.
- Tracking level, depending on pg_stat_statements.track. This part has
been looking at scenarios with DO blocks, PL functions and SQL
functions.
pg_stat_statements.sql (still named the same for now) still includes
some checks for role-level tracking and WAL generation metrics, that
ought to become independent in the long term for clarity.
While on it, this switches the order of the attributes when querying
pg_stat_statements, the query field becoming last. This makes much
easier the tracking of changes related to normalization, as queries are
the only variable-length attributes queried (unaligned mode would be one
extra choice, but that reduces the checks on the other fields).
Test scenarios and their results match exactly with what was happening
before this commit in terms of calls, number of plans, number of rows,
cached data or level tracking, so this has no effect on the coverage in
terms of what is produced by the reports in the table
pg_stat_statements. A follow-up patch will extend more the tests of
pg_stat_statements around utilities, so this split creates a foundation
for this purpose, without complicating more pg_stat_statements.sql.
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 01:28:29 +01:00
|
|
|
(1 row)
|
|
|
|
|