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
3 years ago
|
|
|
--
|
|
|
|
|
-- Utility commands
|
|
|
|
|
--
|
|
|
|
|
-- These tests require track_utility to be enabled.
|
|
|
|
|
SET pg_stat_statements.track_utility = TRUE;
|
|
|
|
|
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
3 years ago
|
|
|
(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
3 years ago
|
|
|
-- 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
|
|
|
|
|
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
3 years ago
|
|
|
(8 rows)
|
|
|
|
|
|
|
|
|
|
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
3 years ago
|
|
|
(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
3 years ago
|
|
|
-- 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
|
|
|
|
|
SET work_mem = '256kB';
|
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
3 years ago
|
|
|
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 +
|
Show values of SET statements as constants in pg_stat_statements
This is a continuation of work like 11c34b342bd7, done to reduce the
bloat of pg_stat_statements by applying more normalization to query
entries. This commit is able to detect and normalize values in
VariableSetStmt, resulting in:
SET conf_param = $1
Compared to other parse nodes, VariableSetStmt is embedded in much more
places in the parser, impacting many query patterns in
pg_stat_statements. A custom jumble function is used, with an extra
field in the node to decide if arguments should be included in the
jumbling or not, a location field being not enough for this purpose.
This approach allows for a finer tuning.
Clauses relying on one or more keywords are not normalized, for example:
* DEFAULT
* FROM CURRENT
* List of keywords. SET SESSION CHARACTERISTICS AS TRANSACTION,
where it is critical to differentiate different sets of options, is a
good example of why normalization should not happen.
Some queries use VariableSetStmt for some subclauses with SET, that also
have their values normalized:
- ALTER DATABASE
- ALTER ROLE
- ALTER SYSTEM
- CREATE/ALTER FUNCTION
ba90eac7a995 has added test coverage for most of the existing SET
patterns. The expected output of these tests shows the difference this
commit creates. Normalization could be perhaps applied to more portions
of the grammar but what is done here is conservative, and good enough as
a starting point.
Author: Greg Sabino Mullane, Michael Paquier
Discussion: https://postgr.es/m/36e5bffe-e989-194f-85c8-06e7bc88e6f7@amazon.com
Discussion: https://postgr.es/m/B44FA29D-EBD0-4DD9-ABC2-16F1CB087074@amazon.com
Discussion: https://postgr.es/m/CAKAnmmJtJY2jzQN91=2QAD2eAJAA-Per61eyO48-TyxEg-q0Rg@mail.gmail.com
1 year ago
|
|
|
| | SET work_mem = $1
|
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
3 years ago
|
|
|
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
|
|
|
|
|
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
3 years ago
|
|
|
(39 rows)
|
|
|
|
|
|
|
|
|
|
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
3 years ago
|
|
|
(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
|
|
|
|
|
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
3 years ago
|
|
|
(8 rows)
|
|
|
|
|
|
|
|
|
|
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
3 years ago
|
|
|
(1 row)
|
|
|
|
|
|
|
|
|
|
-- 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";
|
|
|
|
|
calls | rows | query
|
|
|
|
|
-------+------+----------------------------------------------------
|
|
|
|
|
2 | 0 | BEGIN
|
|
|
|
|
1 | 0 | COMMIT PREPARED $1
|
|
|
|
|
2 | 0 | PREPARE TRANSACTION $1
|
|
|
|
|
1 | 0 | ROLLBACK PREPARED $1
|
|
|
|
|
1 | 1 | SELECT pg_stat_statements_reset() IS NOT NULL AS t
|
|
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
|
t
|
|
|
|
|
---
|
|
|
|
|
t
|
|
|
|
|
(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
2 years ago
|
|
|
-- 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";
|
|
|
|
|
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
2 years ago
|
|
|
1 | 0 | BEGIN
|
|
|
|
|
1 | 0 | COMMIT
|
|
|
|
|
3 | 0 | RELEASE $1
|
|
|
|
|
4 | 0 | ROLLBACK TO $1
|
|
|
|
|
4 | 0 | SAVEPOINT $1
|
|
|
|
|
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
2 years ago
|
|
|
(6 rows)
|
|
|
|
|
|
|
|
|
|
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
2 years ago
|
|
|
(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
3 years ago
|
|
|
-- 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";
|
|
|
|
|
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
|
|
|
|
|
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
3 years ago
|
|
|
(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;
|
|
|
|
|
-- 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;
|
|
|
|
|
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
3 years ago
|
|
|
(1 row)
|
|
|
|
|
|
|
|
|
|
CALL sum_one(3);
|
|
|
|
|
CALL sum_one(199);
|
|
|
|
|
CALL sum_two(1,1);
|
|
|
|
|
CALL sum_two(1,2);
|
|
|
|
|
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
3 years ago
|
|
|
SELECT calls, rows, query FROM pg_stat_statements ORDER BY query COLLATE "C";
|
|
|
|
|
calls | rows | query
|
|
|
|
|
-------+------+----------------------------------------------------
|
|
|
|
|
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)
|
|
|
|
|
1 | 1 | SELECT pg_stat_statements_reset() IS NOT NULL AS t
|
|
|
|
|
(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
3 years ago
|
|
|
|
|
|
|
|
-- COPY
|
|
|
|
|
CREATE TABLE copy_stats (a int, b int);
|
|
|
|
|
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
3 years ago
|
|
|
(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
|
|
|
|
|
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
3 years ago
|
|
|
(8 rows)
|
|
|
|
|
|
|
|
|
|
DROP TABLE copy_stats;
|
|
|
|
|
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
3 years ago
|
|
|
(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";
|
|
|
|
|
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
3 years ago
|
|
|
2 | 0 | DROP TABLE ctas_stats_1
|
|
|
|
|
2 | 0 | DROP TABLE ctas_stats_2
|
|
|
|
|
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
3 years ago
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
|
|
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
3 years ago
|
|
|
(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";
|
|
|
|
|
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
3 years ago
|
|
|
2 | 0 | DROP MATERIALIZED VIEW matview_stats_1
|
|
|
|
|
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
3 years ago
|
|
|
(3 rows)
|
|
|
|
|
|
|
|
|
|
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
3 years ago
|
|
|
(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
|
|
|
|
|
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
3 years ago
|
|
|
(4 rows)
|
|
|
|
|
|
|
|
|
|
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
3 years ago
|
|
|
(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
|
|
|
|
|
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
3 years ago
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
|
|
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
3 years ago
|
|
|
(1 row)
|
|
|
|
|
|
|
|
|
|
-- 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";
|
|
|
|
|
calls | rows | query
|
|
|
|
|
-------+------+----------------------------------------------------
|
|
|
|
|
2 | 0 | DEALLOCATE $1
|
|
|
|
|
2 | 0 | DEALLOCATE ALL
|
Track more precisely query locations for nested statements
Previously, a Query generated through the transform phase would have
unset stmt_location, tracking the starting point of a query string.
Extensions relying on the statement location to extract its relevant
parts in the source text string would fallback to use the whole
statement instead, leading to confusing results like in
pg_stat_statements for queries relying on nested queries, like:
- EXPLAIN, with top-level and nested query using the same query string,
and a query ID coming from the nested query when the non-top-level
entry.
- Multi-statements, with only partial portions of queries being
normalized.
- COPY TO with a query, SELECT or DMLs.
This patch improves things by keeping track of the statement locations
and propagate it to Query during transform, allowing PGSS to only show
the relevant part of the query for nested query. This leads to less
bloat in entries for non-top-level entries, as queries can now be
grouped within the same (toplevel, queryid) duos in pg_stat_statements.
The result gives a stricter one-one mapping between query IDs and its
query strings.
The regression tests introduced in 45e0ba30fc40 produce differences
reflecting the new logic.
Author: Anthonin Bonnefoy
Reviewed-by: Michael Paquier, Jian He
Discussion: https://postgr.es/m/CAO6_XqqM6S9bQ2qd=75W+yKATwoazxSNhv5sjW06fjGAtHbTUA@mail.gmail.com
1 year ago
|
|
|
2 | 2 | SELECT $1 AS a
|
|
|
|
|
1 | 1 | SELECT $1 as a
|
|
|
|
|
1 | 1 | SELECT pg_stat_statements_reset() IS NOT NULL AS t
|
|
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
|
t
|
|
|
|
|
---
|
|
|
|
|
t
|
|
|
|
|
(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
3 years ago
|
|
|
-- SET statements.
|
|
|
|
|
-- These use two different strings, still they count as one entry.
|
|
|
|
|
CREATE ROLE regress_stat_set_1;
|
|
|
|
|
CREATE ROLE regress_stat_set_2;
|
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
3 years ago
|
|
|
SET work_mem = '1MB';
|
|
|
|
|
Set work_mem = '1MB';
|
|
|
|
|
SET work_mem = '2MB';
|
|
|
|
|
SET work_mem = DEFAULT;
|
|
|
|
|
SET work_mem TO DEFAULT;
|
|
|
|
|
SET work_mem FROM CURRENT;
|
|
|
|
|
BEGIN;
|
|
|
|
|
SET LOCAL work_mem = '128kB';
|
|
|
|
|
SET LOCAL work_mem = '256kB';
|
|
|
|
|
SET LOCAL work_mem = DEFAULT;
|
|
|
|
|
SET LOCAL work_mem TO DEFAULT;
|
|
|
|
|
SET LOCAL work_mem FROM CURRENT;
|
|
|
|
|
COMMIT;
|
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
3 years ago
|
|
|
RESET work_mem;
|
|
|
|
|
SET enable_seqscan = off;
|
|
|
|
|
SET enable_seqscan = on;
|
|
|
|
|
SET SESSION work_mem = '300kB';
|
|
|
|
|
SET SESSION work_mem = '400kB';
|
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
3 years ago
|
|
|
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 AUTHORIZATION
|
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
3 years ago
|
|
|
SET SESSION SESSION AUTHORIZATION DEFAULT;
|
|
|
|
|
SET SESSION AUTHORIZATION 'regress_stat_set_1';
|
|
|
|
|
SET SESSION AUTHORIZATION 'regress_stat_set_2';
|
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
3 years ago
|
|
|
RESET SESSION AUTHORIZATION;
|
|
|
|
|
BEGIN;
|
|
|
|
|
SET LOCAL SESSION AUTHORIZATION DEFAULT;
|
|
|
|
|
SET LOCAL SESSION AUTHORIZATION 'regress_stat_set_1';
|
|
|
|
|
SET LOCAL SESSION AUTHORIZATION 'regress_stat_set_2';
|
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
3 years ago
|
|
|
RESET SESSION AUTHORIZATION;
|
|
|
|
|
COMMIT;
|
|
|
|
|
-- SET SESSION CHARACTERISTICS
|
|
|
|
|
SET SESSION CHARACTERISTICS AS TRANSACTION READ ONLY;
|
|
|
|
|
SET SESSION CHARACTERISTICS AS TRANSACTION READ ONLY, READ ONLY;
|
|
|
|
|
SET SESSION CHARACTERISTICS AS TRANSACTION READ ONLY, READ WRITE;
|
|
|
|
|
-- SET XML OPTION
|
|
|
|
|
SET XML OPTION DOCUMENT;
|
|
|
|
|
SET XML OPTION CONTENT;
|
|
|
|
|
-- SET TIME ZONE
|
|
|
|
|
SET TIME ZONE 'America/New_York';
|
|
|
|
|
SET TIME ZONE 'Asia/Tokyo';
|
|
|
|
|
SET TIME ZONE DEFAULT;
|
|
|
|
|
SET TIME ZONE LOCAL;
|
|
|
|
|
SET TIME ZONE 'CST7CDT,M4.1.0,M10.5.0';
|
|
|
|
|
RESET TIME ZONE;
|
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
3 years ago
|
|
|
SELECT calls, rows, query FROM pg_stat_statements ORDER BY query COLLATE "C";
|
|
|
|
|
calls | rows | query
|
|
|
|
|
-------+------+------------------------------------------------------------------
|
|
|
|
|
3 | 0 | BEGIN
|
|
|
|
|
3 | 0 | COMMIT
|
|
|
|
|
1 | 0 | CREATE ROLE regress_stat_set_1
|
|
|
|
|
1 | 0 | CREATE ROLE regress_stat_set_2
|
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
3 years ago
|
|
|
2 | 0 | RESET SESSION AUTHORIZATION
|
|
|
|
|
1 | 0 | RESET TIME ZONE
|
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
3 years ago
|
|
|
1 | 0 | RESET enable_seqscan
|
|
|
|
|
1 | 0 | RESET work_mem
|
|
|
|
|
1 | 1 | SELECT pg_stat_statements_reset() IS NOT NULL AS t
|
|
|
|
|
1 | 0 | SET LOCAL SESSION AUTHORIZATION 'regress_stat_set_1'
|
|
|
|
|
1 | 0 | SET LOCAL SESSION AUTHORIZATION 'regress_stat_set_2'
|
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
3 years ago
|
|
|
1 | 0 | SET LOCAL SESSION AUTHORIZATION DEFAULT
|
Show values of SET statements as constants in pg_stat_statements
This is a continuation of work like 11c34b342bd7, done to reduce the
bloat of pg_stat_statements by applying more normalization to query
entries. This commit is able to detect and normalize values in
VariableSetStmt, resulting in:
SET conf_param = $1
Compared to other parse nodes, VariableSetStmt is embedded in much more
places in the parser, impacting many query patterns in
pg_stat_statements. A custom jumble function is used, with an extra
field in the node to decide if arguments should be included in the
jumbling or not, a location field being not enough for this purpose.
This approach allows for a finer tuning.
Clauses relying on one or more keywords are not normalized, for example:
* DEFAULT
* FROM CURRENT
* List of keywords. SET SESSION CHARACTERISTICS AS TRANSACTION,
where it is critical to differentiate different sets of options, is a
good example of why normalization should not happen.
Some queries use VariableSetStmt for some subclauses with SET, that also
have their values normalized:
- ALTER DATABASE
- ALTER ROLE
- ALTER SYSTEM
- CREATE/ALTER FUNCTION
ba90eac7a995 has added test coverage for most of the existing SET
patterns. The expected output of these tests shows the difference this
commit creates. Normalization could be perhaps applied to more portions
of the grammar but what is done here is conservative, and good enough as
a starting point.
Author: Greg Sabino Mullane, Michael Paquier
Discussion: https://postgr.es/m/36e5bffe-e989-194f-85c8-06e7bc88e6f7@amazon.com
Discussion: https://postgr.es/m/B44FA29D-EBD0-4DD9-ABC2-16F1CB087074@amazon.com
Discussion: https://postgr.es/m/CAKAnmmJtJY2jzQN91=2QAD2eAJAA-Per61eyO48-TyxEg-q0Rg@mail.gmail.com
1 year ago
|
|
|
2 | 0 | SET LOCAL work_mem = $1
|
|
|
|
|
2 | 0 | SET LOCAL work_mem = DEFAULT
|
|
|
|
|
1 | 0 | SET LOCAL work_mem FROM CURRENT
|
|
|
|
|
1 | 0 | SET SESSION AUTHORIZATION 'regress_stat_set_1'
|
|
|
|
|
1 | 0 | SET SESSION AUTHORIZATION 'regress_stat_set_2'
|
|
|
|
|
1 | 0 | SET SESSION CHARACTERISTICS AS TRANSACTION READ ONLY
|
|
|
|
|
1 | 0 | SET SESSION CHARACTERISTICS AS TRANSACTION READ ONLY, READ ONLY
|
|
|
|
|
1 | 0 | SET SESSION CHARACTERISTICS AS TRANSACTION READ ONLY, READ WRITE
|
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
3 years ago
|
|
|
1 | 0 | SET SESSION SESSION AUTHORIZATION DEFAULT
|
|
|
|
|
1 | 0 | SET TIME ZONE 'America/New_York'
|
|
|
|
|
1 | 0 | SET TIME ZONE 'Asia/Tokyo'
|
|
|
|
|
1 | 0 | SET TIME ZONE 'CST7CDT,M4.1.0,M10.5.0'
|
|
|
|
|
2 | 0 | SET TIME ZONE DEFAULT
|
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
3 years ago
|
|
|
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 XML OPTION CONTENT
|
|
|
|
|
1 | 0 | SET XML OPTION DOCUMENT
|
Show values of SET statements as constants in pg_stat_statements
This is a continuation of work like 11c34b342bd7, done to reduce the
bloat of pg_stat_statements by applying more normalization to query
entries. This commit is able to detect and normalize values in
VariableSetStmt, resulting in:
SET conf_param = $1
Compared to other parse nodes, VariableSetStmt is embedded in much more
places in the parser, impacting many query patterns in
pg_stat_statements. A custom jumble function is used, with an extra
field in the node to decide if arguments should be included in the
jumbling or not, a location field being not enough for this purpose.
This approach allows for a finer tuning.
Clauses relying on one or more keywords are not normalized, for example:
* DEFAULT
* FROM CURRENT
* List of keywords. SET SESSION CHARACTERISTICS AS TRANSACTION,
where it is critical to differentiate different sets of options, is a
good example of why normalization should not happen.
Some queries use VariableSetStmt for some subclauses with SET, that also
have their values normalized:
- ALTER DATABASE
- ALTER ROLE
- ALTER SYSTEM
- CREATE/ALTER FUNCTION
ba90eac7a995 has added test coverage for most of the existing SET
patterns. The expected output of these tests shows the difference this
commit creates. Normalization could be perhaps applied to more portions
of the grammar but what is done here is conservative, and good enough as
a starting point.
Author: Greg Sabino Mullane, Michael Paquier
Discussion: https://postgr.es/m/36e5bffe-e989-194f-85c8-06e7bc88e6f7@amazon.com
Discussion: https://postgr.es/m/B44FA29D-EBD0-4DD9-ABC2-16F1CB087074@amazon.com
Discussion: https://postgr.es/m/CAKAnmmJtJY2jzQN91=2QAD2eAJAA-Per61eyO48-TyxEg-q0Rg@mail.gmail.com
1 year ago
|
|
|
2 | 0 | SET enable_seqscan = $1
|
|
|
|
|
5 | 0 | SET work_mem = $1
|
|
|
|
|
2 | 0 | SET work_mem = DEFAULT
|
|
|
|
|
1 | 0 | SET work_mem FROM CURRENT
|
Show values of SET statements as constants in pg_stat_statements
This is a continuation of work like 11c34b342bd7, done to reduce the
bloat of pg_stat_statements by applying more normalization to query
entries. This commit is able to detect and normalize values in
VariableSetStmt, resulting in:
SET conf_param = $1
Compared to other parse nodes, VariableSetStmt is embedded in much more
places in the parser, impacting many query patterns in
pg_stat_statements. A custom jumble function is used, with an extra
field in the node to decide if arguments should be included in the
jumbling or not, a location field being not enough for this purpose.
This approach allows for a finer tuning.
Clauses relying on one or more keywords are not normalized, for example:
* DEFAULT
* FROM CURRENT
* List of keywords. SET SESSION CHARACTERISTICS AS TRANSACTION,
where it is critical to differentiate different sets of options, is a
good example of why normalization should not happen.
Some queries use VariableSetStmt for some subclauses with SET, that also
have their values normalized:
- ALTER DATABASE
- ALTER ROLE
- ALTER SYSTEM
- CREATE/ALTER FUNCTION
ba90eac7a995 has added test coverage for most of the existing SET
patterns. The expected output of these tests shows the difference this
commit creates. Normalization could be perhaps applied to more portions
of the grammar but what is done here is conservative, and good enough as
a starting point.
Author: Greg Sabino Mullane, Michael Paquier
Discussion: https://postgr.es/m/36e5bffe-e989-194f-85c8-06e7bc88e6f7@amazon.com
Discussion: https://postgr.es/m/B44FA29D-EBD0-4DD9-ABC2-16F1CB087074@amazon.com
Discussion: https://postgr.es/m/CAKAnmmJtJY2jzQN91=2QAD2eAJAA-Per61eyO48-TyxEg-q0Rg@mail.gmail.com
1 year ago
|
|
|
(34 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
3 years ago
|
|
|
|
|
|
|
|
DROP ROLE regress_stat_set_1;
|
|
|
|
|
DROP ROLE regress_stat_set_2;
|
|
|
|
|
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
3 years ago
|
|
|
(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";
|
|
|
|
|
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
3 years ago
|
|
|
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
|
|
|
|
|
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
3 years ago
|
|
|
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
|
|
|
|
|
1 | 10 | SELECT generate_series($1, $2) c INTO pgss_select_into
|
|
|
|
|
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
3 years ago
|
|
|
(12 rows)
|
|
|
|
|
|
|
|
|
|
DROP MATERIALIZED VIEW pgss_matv;
|
|
|
|
|
DROP TABLE pgss_ctas;
|
|
|
|
|
DROP TABLE pgss_select_into;
|
|
|
|
|
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
3 years ago
|
|
|
(1 row)
|
|
|
|
|
|
|
|
|
|
-- Special cases. Keep these ones at the end to avoid conflicts.
|
|
|
|
|
SET SCHEMA 'foo';
|
|
|
|
|
SET SCHEMA 'public';
|
|
|
|
|
RESET ALL;
|
|
|
|
|
SELECT calls, rows, query FROM pg_stat_statements ORDER BY query COLLATE "C";
|
|
|
|
|
calls | rows | query
|
|
|
|
|
-------+------+----------------------------------------------------
|
|
|
|
|
1 | 0 | RESET ALL
|
|
|
|
|
1 | 1 | SELECT pg_stat_statements_reset() IS NOT NULL AS t
|
Show values of SET statements as constants in pg_stat_statements
This is a continuation of work like 11c34b342bd7, done to reduce the
bloat of pg_stat_statements by applying more normalization to query
entries. This commit is able to detect and normalize values in
VariableSetStmt, resulting in:
SET conf_param = $1
Compared to other parse nodes, VariableSetStmt is embedded in much more
places in the parser, impacting many query patterns in
pg_stat_statements. A custom jumble function is used, with an extra
field in the node to decide if arguments should be included in the
jumbling or not, a location field being not enough for this purpose.
This approach allows for a finer tuning.
Clauses relying on one or more keywords are not normalized, for example:
* DEFAULT
* FROM CURRENT
* List of keywords. SET SESSION CHARACTERISTICS AS TRANSACTION,
where it is critical to differentiate different sets of options, is a
good example of why normalization should not happen.
Some queries use VariableSetStmt for some subclauses with SET, that also
have their values normalized:
- ALTER DATABASE
- ALTER ROLE
- ALTER SYSTEM
- CREATE/ALTER FUNCTION
ba90eac7a995 has added test coverage for most of the existing SET
patterns. The expected output of these tests shows the difference this
commit creates. Normalization could be perhaps applied to more portions
of the grammar but what is done here is conservative, and good enough as
a starting point.
Author: Greg Sabino Mullane, Michael Paquier
Discussion: https://postgr.es/m/36e5bffe-e989-194f-85c8-06e7bc88e6f7@amazon.com
Discussion: https://postgr.es/m/B44FA29D-EBD0-4DD9-ABC2-16F1CB087074@amazon.com
Discussion: https://postgr.es/m/CAKAnmmJtJY2jzQN91=2QAD2eAJAA-Per61eyO48-TyxEg-q0Rg@mail.gmail.com
1 year ago
|
|
|
2 | 0 | SET SCHEMA $1
|
|
|
|
|
(3 rows)
|
|
|
|
|
|
|
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
|
t
|
|
|
|
|
---
|
|
|
|
|
t
|
|
|
|
|
(1 row)
|
|
|
|
|
|