Refactor tests of pg_stat_statements for planning, utility and level tracking
pg_stat_statements.sql acts as the main file for all the core tests of
the module, but things have become complicated to follow over the years
as some of the sub-scenarios tested in this file rely on assumptions
that come from completely different areas of it, like a GUC setup or a
relation created previously. For example, row tracking for CTAS/COPY
was looking at the number of plans, which was not necessary, or level
tracking was mixed with checks on planner counts.
This commit refactors the tests of pg_stat_statements, by moving test
cases out of pg_stat_statements.sql into their own file, as of:
- Planning-related tests in planning.sql, for [re]plan counts and
top-level handling. These depend on pg_stat_statements.track_planning.
- Utilities in utility.sql (pg_stat_statements.track_utility), that
includes now the tests for:
-- Row tracking for CTAS, CREATE MATERIALIZED VIEW, COPY.
-- Basic utility statements.
-- SET statements.
- Tracking level, depending on pg_stat_statements.track. This part has
been looking at scenarios with DO blocks, PL functions and SQL
functions.
pg_stat_statements.sql (still named the same for now) still includes
some checks for role-level tracking and WAL generation metrics, that
ought to become independent in the long term for clarity.
While on it, this switches the order of the attributes when querying
pg_stat_statements, the query field becoming last. This makes much
easier the tracking of changes related to normalization, as queries are
the only variable-length attributes queried (unaligned mode would be one
extra choice, but that reduces the checks on the other fields).
Test scenarios and their results match exactly with what was happening
before this commit in terms of calls, number of plans, number of rows,
cached data or level tracking, so this has no effect on the coverage in
terms of what is produced by the reports in the table
pg_stat_statements. A follow-up patch will extend more the tests of
pg_stat_statements around utilities, so this split creates a foundation
for this purpose, without complicating more pg_stat_statements.sql.
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 01:28:29 +01:00
|
|
|
--
|
|
|
|
|
-- Information related to planning
|
|
|
|
|
--
|
|
|
|
|
|
|
|
|
|
-- These tests require track_planning to be enabled.
|
|
|
|
|
SET pg_stat_statements.track_planning = TRUE;
|
2023-11-27 01:50:59 +01:00
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
Refactor tests of pg_stat_statements for planning, utility and level tracking
pg_stat_statements.sql acts as the main file for all the core tests of
the module, but things have become complicated to follow over the years
as some of the sub-scenarios tested in this file rely on assumptions
that come from completely different areas of it, like a GUC setup or a
relation created previously. For example, row tracking for CTAS/COPY
was looking at the number of plans, which was not necessary, or level
tracking was mixed with checks on planner counts.
This commit refactors the tests of pg_stat_statements, by moving test
cases out of pg_stat_statements.sql into their own file, as of:
- Planning-related tests in planning.sql, for [re]plan counts and
top-level handling. These depend on pg_stat_statements.track_planning.
- Utilities in utility.sql (pg_stat_statements.track_utility), that
includes now the tests for:
-- Row tracking for CTAS, CREATE MATERIALIZED VIEW, COPY.
-- Basic utility statements.
-- SET statements.
- Tracking level, depending on pg_stat_statements.track. This part has
been looking at scenarios with DO blocks, PL functions and SQL
functions.
pg_stat_statements.sql (still named the same for now) still includes
some checks for role-level tracking and WAL generation metrics, that
ought to become independent in the long term for clarity.
While on it, this switches the order of the attributes when querying
pg_stat_statements, the query field becoming last. This makes much
easier the tracking of changes related to normalization, as queries are
the only variable-length attributes queried (unaligned mode would be one
extra choice, but that reduces the checks on the other fields).
Test scenarios and their results match exactly with what was happening
before this commit in terms of calls, number of plans, number of rows,
cached data or level tracking, so this has no effect on the coverage in
terms of what is produced by the reports in the table
pg_stat_statements. A follow-up patch will extend more the tests of
pg_stat_statements around utilities, so this split creates a foundation
for this purpose, without complicating more pg_stat_statements.sql.
Reviewed-by: Bertrand Drouvot
Discussion: https://postgr.es/m/Y+MRdEq9W9XVa2AB@paquier.xyz
2023-02-20 01:28:29 +01:00
|
|
|
|
|
|
|
|
--
|
|
|
|
|
-- [re]plan counting
|
|
|
|
|
--
|
|
|
|
|
CREATE TABLE stats_plan_test ();
|
|
|
|
|
PREPARE prep1 AS SELECT COUNT(*) FROM stats_plan_test;
|
|
|
|
|
EXECUTE prep1;
|
|
|
|
|
EXECUTE prep1;
|
|
|
|
|
EXECUTE prep1;
|
|
|
|
|
ALTER TABLE stats_plan_test ADD COLUMN x int;
|
|
|
|
|
EXECUTE prep1;
|
|
|
|
|
SELECT 42;
|
|
|
|
|
SELECT 42;
|
|
|
|
|
SELECT 42;
|
|
|
|
|
SELECT plans, calls, rows, query FROM pg_stat_statements
|
|
|
|
|
WHERE query NOT LIKE 'PREPARE%' ORDER BY query COLLATE "C";
|
|
|
|
|
-- for the prepared statement we expect at least one replan, but cache
|
|
|
|
|
-- invalidations could force more
|
|
|
|
|
SELECT plans >= 2 AND plans <= calls AS plans_ok, calls, rows, query FROM pg_stat_statements
|
|
|
|
|
WHERE query LIKE 'PREPARE%' ORDER BY query COLLATE "C";
|
|
|
|
|
|
|
|
|
|
-- Cleanup
|
|
|
|
|
DROP TABLE stats_plan_test;
|
2023-11-27 01:50:59 +01:00
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
