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 09:28:29 +09:00
|
|
|
--
|
|
|
|
-- Statement level tracking
|
|
|
|
--
|
|
|
|
|
|
|
|
SET pg_stat_statements.track_utility = TRUE;
|
2023-11-27 02:50:59 +02: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 09:28:29 +09:00
|
|
|
|
|
|
|
-- DO block - top-level tracking.
|
|
|
|
CREATE TABLE stats_track_tab (x int);
|
|
|
|
SET pg_stat_statements.track = 'top';
|
|
|
|
DELETE FROM stats_track_tab;
|
|
|
|
DO $$
|
|
|
|
BEGIN
|
|
|
|
DELETE FROM stats_track_tab;
|
|
|
|
END;
|
|
|
|
$$ LANGUAGE plpgsql;
|
|
|
|
SELECT toplevel, calls, query FROM pg_stat_statements
|
|
|
|
WHERE query LIKE '%DELETE%' ORDER BY query COLLATE "C", toplevel;
|
2023-11-27 02:50:59 +02: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 09:28:29 +09:00
|
|
|
|
|
|
|
-- DO block - all-level tracking.
|
|
|
|
SET pg_stat_statements.track = 'all';
|
|
|
|
DELETE FROM stats_track_tab;
|
|
|
|
DO $$
|
|
|
|
BEGIN
|
|
|
|
DELETE FROM stats_track_tab;
|
|
|
|
END; $$;
|
|
|
|
DO LANGUAGE plpgsql $$
|
|
|
|
BEGIN
|
|
|
|
-- this is a SELECT
|
|
|
|
PERFORM 'hello world'::TEXT;
|
|
|
|
END; $$;
|
|
|
|
SELECT toplevel, calls, query FROM pg_stat_statements
|
|
|
|
ORDER BY query COLLATE "C", toplevel;
|
|
|
|
|
2024-07-19 10:21:01 +09:00
|
|
|
-- Procedure with multiple utility statements.
|
|
|
|
CREATE OR REPLACE PROCEDURE proc_with_utility_stmt()
|
|
|
|
LANGUAGE SQL
|
|
|
|
AS $$
|
|
|
|
SHOW pg_stat_statements.track;
|
|
|
|
show pg_stat_statements.track;
|
|
|
|
SHOW pg_stat_statements.track_utility;
|
|
|
|
$$;
|
|
|
|
SET pg_stat_statements.track_utility = TRUE;
|
|
|
|
-- all-level tracking.
|
|
|
|
SET pg_stat_statements.track = 'all';
|
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
CALL proc_with_utility_stmt();
|
|
|
|
SELECT toplevel, calls, query FROM pg_stat_statements
|
|
|
|
ORDER BY query COLLATE "C", toplevel;
|
|
|
|
-- top-level tracking.
|
|
|
|
SET pg_stat_statements.track = 'top';
|
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
CALL proc_with_utility_stmt();
|
|
|
|
SELECT toplevel, calls, query FROM pg_stat_statements
|
|
|
|
ORDER BY query COLLATE "C", toplevel;
|
|
|
|
|
2024-10-22 13:05:51 +09:00
|
|
|
-- EXPLAIN - all-level tracking.
|
|
|
|
CREATE TABLE test_table (x int);
|
|
|
|
SET pg_stat_statements.track = 'all';
|
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
EXPLAIN (COSTS OFF) SELECT 1;
|
|
|
|
EXPLAIN (COSTS OFF) (SELECT 1, 2);
|
|
|
|
EXPLAIN (COSTS OFF) TABLE stats_track_tab;
|
|
|
|
EXPLAIN (COSTS OFF) (TABLE test_table);
|
|
|
|
EXPLAIN (COSTS OFF) VALUES (1);
|
|
|
|
EXPLAIN (COSTS OFF) (VALUES (1, 2));
|
|
|
|
EXPLAIN (COSTS OFF) UPDATE stats_track_tab SET x = 1 WHERE x = 1;
|
|
|
|
EXPLAIN (COSTS OFF) DELETE FROM stats_track_tab;
|
|
|
|
EXPLAIN (COSTS OFF) INSERT INTO stats_track_tab VALUES ((1));
|
|
|
|
EXPLAIN (COSTS OFF) MERGE INTO stats_track_tab
|
|
|
|
USING (SELECT id FROM generate_series(1, 10) id) ON x = id
|
|
|
|
WHEN MATCHED THEN UPDATE SET x = id
|
|
|
|
WHEN NOT MATCHED THEN INSERT (x) VALUES (id);
|
|
|
|
EXPLAIN (COSTS OFF) SELECT 1 UNION SELECT 2;
|
|
|
|
SELECT toplevel, calls, query FROM pg_stat_statements
|
|
|
|
ORDER BY query COLLATE "C";
|
|
|
|
|
|
|
|
-- EXPLAIN - top-level tracking.
|
|
|
|
SET pg_stat_statements.track = 'top';
|
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
EXPLAIN (COSTS OFF) SELECT 1;
|
|
|
|
EXPLAIN (COSTS OFF) (SELECT 1, 2);
|
|
|
|
EXPLAIN (COSTS OFF) TABLE stats_track_tab;
|
|
|
|
EXPLAIN (COSTS OFF) (TABLE test_table);
|
|
|
|
EXPLAIN (COSTS OFF) VALUES (1);
|
|
|
|
EXPLAIN (COSTS OFF) (VALUES (1, 2));
|
|
|
|
EXPLAIN (COSTS OFF) UPDATE stats_track_tab SET x = 1 WHERE x = 1;
|
|
|
|
EXPLAIN (COSTS OFF) DELETE FROM stats_track_tab;
|
|
|
|
EXPLAIN (COSTS OFF) INSERT INTO stats_track_tab VALUES ((1));
|
|
|
|
EXPLAIN (COSTS OFF) MERGE INTO stats_track_tab
|
|
|
|
USING (SELECT id FROM generate_series(1, 10) id) ON x = id
|
|
|
|
WHEN MATCHED THEN UPDATE SET x = id
|
|
|
|
WHEN NOT MATCHED THEN INSERT (x) VALUES (id);
|
|
|
|
EXPLAIN (COSTS OFF) SELECT 1 UNION SELECT 2;
|
|
|
|
SELECT toplevel, calls, query FROM pg_stat_statements
|
|
|
|
ORDER BY query COLLATE "C";
|
|
|
|
|
|
|
|
-- EXPLAIN - all-level tracking with multi-statement strings.
|
|
|
|
SET pg_stat_statements.track = 'all';
|
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
-- SELECT queries
|
|
|
|
EXPLAIN (COSTS OFF) SELECT 1\; EXPLAIN (COSTS OFF) SELECT 1, 2;
|
|
|
|
EXPLAIN (COSTS OFF) (SELECT 1, 2, 3)\; EXPLAIN (COSTS OFF) (SELECT 1, 2, 3, 4);
|
|
|
|
EXPLAIN (COSTS OFF) SELECT 1, 2 UNION SELECT 3, 4\; EXPLAIN (COSTS OFF) (SELECT 1, 2, 3) UNION SELECT 3, 4, 5;
|
|
|
|
SELECT toplevel, calls, query FROM pg_stat_statements
|
|
|
|
ORDER BY query COLLATE "C";
|
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
-- Most DMLs
|
|
|
|
EXPLAIN (COSTS OFF) TABLE stats_track_tab\; EXPLAIN (COSTS OFF) (TABLE test_table);
|
|
|
|
EXPLAIN (COSTS OFF) VALUES (1)\; EXPLAIN (COSTS OFF) (VALUES (1, 2));
|
|
|
|
EXPLAIN (COSTS OFF) UPDATE stats_track_tab SET x = 1 WHERE x = 1\; EXPLAIN (COSTS OFF) UPDATE stats_track_tab SET x = 1;
|
|
|
|
EXPLAIN (COSTS OFF) DELETE FROM stats_track_tab\; EXPLAIN (COSTS OFF) DELETE FROM stats_track_tab WHERE x = 1;
|
|
|
|
EXPLAIN (COSTS OFF) INSERT INTO stats_track_tab VALUES ((1))\; EXPLAIN (COSTS OFF) INSERT INTO stats_track_tab VALUES (1), (2);
|
|
|
|
SELECT toplevel, calls, query FROM pg_stat_statements
|
|
|
|
ORDER BY query COLLATE "C";
|
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
-- MERGE, worth its own.
|
|
|
|
EXPLAIN (COSTS OFF) MERGE INTO stats_track_tab
|
|
|
|
USING (SELECT id FROM generate_series(1, 10) id) ON x = id
|
|
|
|
WHEN MATCHED THEN UPDATE SET x = id
|
|
|
|
WHEN NOT MATCHED THEN INSERT (x) VALUES (id)\; EXPLAIN (COSTS OFF) SELECT 1, 2, 3, 4, 5;
|
|
|
|
SELECT toplevel, calls, query FROM pg_stat_statements
|
|
|
|
ORDER BY query COLLATE "C";
|
|
|
|
|
|
|
|
-- EXPLAIN - top-level tracking with multi-statement strings.
|
|
|
|
SET pg_stat_statements.track = 'top';
|
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
EXPLAIN (COSTS OFF) SELECT 1\; EXPLAIN (COSTS OFF) SELECT 1, 2;
|
|
|
|
EXPLAIN (COSTS OFF) (SELECT 1, 2, 3)\; EXPLAIN (COSTS OFF) (SELECT 1, 2, 3, 4);
|
|
|
|
EXPLAIN (COSTS OFF) TABLE stats_track_tab\; EXPLAIN (COSTS OFF) (TABLE test_table);
|
|
|
|
EXPLAIN (COSTS OFF) VALUES (1)\; EXPLAIN (COSTS OFF) (VALUES (1, 2));
|
|
|
|
EXPLAIN (COSTS OFF) UPDATE stats_track_tab SET x = 1 WHERE x = 1\; EXPLAIN (COSTS OFF) UPDATE stats_track_tab SET x = 1;
|
|
|
|
EXPLAIN (COSTS OFF) DELETE FROM stats_track_tab\; EXPLAIN (COSTS OFF) DELETE FROM stats_track_tab WHERE x = 1;
|
|
|
|
EXPLAIN (COSTS OFF) INSERT INTO stats_track_tab VALUES ((1))\; EXPLAIN (COSTS OFF) INSERT INTO stats_track_tab VALUES ((1), (2));
|
|
|
|
EXPLAIN (COSTS OFF) MERGE INTO stats_track_tab USING (SELECT id FROM generate_series(1, 10) id) ON x = id
|
|
|
|
WHEN MATCHED THEN UPDATE SET x = id
|
|
|
|
WHEN NOT MATCHED THEN INSERT (x) VALUES (id)\; EXPLAIN (COSTS OFF) SELECT 1, 2, 3, 4, 5;
|
|
|
|
EXPLAIN (COSTS OFF) SELECT 1, 2 UNION SELECT 3, 4\; EXPLAIN (COSTS OFF) (SELECT 1, 2, 3) UNION SELECT 3, 4, 5;
|
|
|
|
SELECT toplevel, calls, query FROM pg_stat_statements
|
|
|
|
ORDER BY query COLLATE "C";
|
|
|
|
|
|
|
|
-- EXPLAIN with CTEs - all-level tracking
|
|
|
|
SET pg_stat_statements.track = 'all';
|
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
EXPLAIN (COSTS OFF) WITH a AS (SELECT 4) SELECT 1;
|
|
|
|
EXPLAIN (COSTS OFF) (WITH a AS (SELECT 4) (SELECT 1, 2));
|
|
|
|
EXPLAIN (COSTS OFF) WITH a AS (SELECT 4) UPDATE stats_track_tab SET x = 1 WHERE x = 1;
|
|
|
|
EXPLAIN (COSTS OFF) WITH a AS (SELECT 4) DELETE FROM stats_track_tab;
|
|
|
|
EXPLAIN (COSTS OFF) WITH a AS (SELECT 4) INSERT INTO stats_track_tab VALUES ((1));
|
|
|
|
EXPLAIN (COSTS OFF) WITH a AS (SELECT 4) MERGE INTO stats_track_tab
|
|
|
|
USING (SELECT id FROM generate_series(1, 10) id) ON x = id
|
|
|
|
WHEN MATCHED THEN UPDATE SET x = id
|
|
|
|
WHEN NOT MATCHED THEN INSERT (x) VALUES (id);
|
|
|
|
EXPLAIN (COSTS OFF) WITH a AS (select 4) SELECT 1 UNION SELECT 2;
|
|
|
|
SELECT toplevel, calls, query FROM pg_stat_statements
|
|
|
|
ORDER BY query COLLATE "C";
|
|
|
|
|
|
|
|
-- EXPLAIN with CTEs - top-level tracking
|
|
|
|
SET pg_stat_statements.track = 'top';
|
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
EXPLAIN (COSTS OFF) WITH a AS (SELECT 4) SELECT 1;
|
|
|
|
EXPLAIN (COSTS OFF) (WITH a AS (SELECT 4) (SELECT 1, 2));
|
|
|
|
EXPLAIN (COSTS OFF) WITH a AS (SELECT 4) UPDATE stats_track_tab SET x = 1 WHERE x = 1;
|
|
|
|
EXPLAIN (COSTS OFF) WITH a AS (SELECT 4) DELETE FROM stats_track_tab;
|
|
|
|
EXPLAIN (COSTS OFF) WITH a AS (SELECT 4) INSERT INTO stats_track_tab VALUES ((1));
|
|
|
|
EXPLAIN (COSTS OFF) WITH a AS (SELECT 4) MERGE INTO stats_track_tab
|
|
|
|
USING (SELECT id FROM generate_series(1, 10) id) ON x = id
|
|
|
|
WHEN MATCHED THEN UPDATE SET x = id
|
|
|
|
WHEN NOT MATCHED THEN INSERT (x) VALUES (id);
|
|
|
|
EXPLAIN (COSTS OFF) WITH a AS (select 4) SELECT 1 UNION SELECT 2;
|
|
|
|
SELECT toplevel, calls, query FROM pg_stat_statements
|
|
|
|
ORDER BY query COLLATE "C";
|
|
|
|
|
|
|
|
-- Explain analyze, all-level tracking.
|
|
|
|
SET pg_stat_statements.track = 'all';
|
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
2024-12-12 09:50:00 +13:00
|
|
|
EXPLAIN (ANALYZE, COSTS OFF, SUMMARY OFF, TIMING OFF, BUFFERS OFF) SELECT 100;
|
|
|
|
EXPLAIN (ANALYZE, COSTS OFF, SUMMARY OFF, TIMING OFF, BUFFERS OFF)
|
2024-10-22 13:05:51 +09:00
|
|
|
DECLARE foocur CURSOR FOR SELECT * FROM stats_track_tab;
|
|
|
|
SELECT toplevel, calls, query FROM pg_stat_statements
|
|
|
|
ORDER BY query COLLATE "C";
|
|
|
|
|
|
|
|
-- Explain analyze, top tracking.
|
|
|
|
SET pg_stat_statements.track = 'top';
|
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
2024-12-12 09:50:00 +13:00
|
|
|
EXPLAIN (ANALYZE, COSTS OFF, SUMMARY OFF, TIMING OFF, BUFFERS OFF) SELECT 100;
|
|
|
|
EXPLAIN (ANALYZE, COSTS OFF, SUMMARY OFF, TIMING OFF, BUFFERS OFF)
|
2024-10-22 13:05:51 +09:00
|
|
|
DECLARE foocur CURSOR FOR SELECT * FROM stats_track_tab;
|
|
|
|
SELECT toplevel, calls, query FROM pg_stat_statements
|
|
|
|
ORDER BY query COLLATE "C";
|
|
|
|
|
|
|
|
-- Create Materialized View, all-level tracking.
|
|
|
|
SET pg_stat_statements.track = 'all';
|
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
CREATE MATERIALIZED VIEW pgss_materialized_view AS
|
|
|
|
SELECT * FROM generate_series(1, 5) as id;
|
|
|
|
SELECT toplevel, calls, query FROM pg_stat_statements
|
|
|
|
ORDER BY query COLLATE "C";
|
|
|
|
|
|
|
|
-- CREATE MATERIALIZED VIEW, top-level tracking.
|
|
|
|
SET pg_stat_statements.track = 'top';
|
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
CREATE MATERIALIZED VIEW pgss_materialized_view_2 AS
|
|
|
|
SELECT * FROM generate_series(1, 5) as id;
|
|
|
|
SELECT toplevel, calls, query FROM pg_stat_statements
|
|
|
|
ORDER BY query COLLATE "C";
|
|
|
|
|
|
|
|
-- REFRESH MATERIALIZED VIEW, all-level tracking.
|
|
|
|
SET pg_stat_statements.track = 'all';
|
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
REFRESH MATERIALIZED VIEW pgss_materialized_view;
|
|
|
|
SELECT toplevel, calls, query FROM pg_stat_statements
|
|
|
|
ORDER BY query COLLATE "C";
|
|
|
|
|
|
|
|
-- REFRESH MATERIALIZED VIEW, top-level tracking.
|
|
|
|
SET pg_stat_statements.track = 'top';
|
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
REFRESH MATERIALIZED VIEW pgss_materialized_view;
|
|
|
|
SELECT toplevel, calls, query FROM pg_stat_statements
|
|
|
|
ORDER BY query COLLATE "C";
|
|
|
|
|
|
|
|
-- CREATE TABLE AS, all-level tracking.
|
|
|
|
SET pg_stat_statements.track = 'all';
|
|
|
|
PREPARE test_prepare_pgss AS select generate_series(1, 10);
|
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
CREATE TEMPORARY TABLE pgss_ctas_1 AS SELECT 1;
|
|
|
|
CREATE TEMPORARY TABLE pgss_ctas_2 AS EXECUTE test_prepare_pgss;
|
|
|
|
SELECT toplevel, calls, query FROM pg_stat_statements
|
|
|
|
ORDER BY query COLLATE "C";
|
|
|
|
|
|
|
|
-- CREATE TABLE AS, top-level tracking.
|
|
|
|
SET pg_stat_statements.track = 'top';
|
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
CREATE TEMPORARY TABLE pgss_ctas_3 AS SELECT 1;
|
|
|
|
CREATE TEMPORARY TABLE pgss_ctas_4 AS EXECUTE test_prepare_pgss;
|
|
|
|
SELECT toplevel, calls, query FROM pg_stat_statements
|
|
|
|
ORDER BY query COLLATE "C";
|
|
|
|
|
|
|
|
-- EXPLAIN with CREATE TABLE AS - all-level tracking.
|
|
|
|
SET pg_stat_statements.track = 'all';
|
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
EXPLAIN (COSTS OFF) CREATE TEMPORARY TABLE pgss_explain_ctas AS SELECT 1;
|
|
|
|
SELECT toplevel, calls, query FROM pg_stat_statements
|
|
|
|
ORDER BY query COLLATE "C";
|
|
|
|
|
|
|
|
-- EXPLAIN with CREATE TABLE AS - top-level tracking.
|
|
|
|
SET pg_stat_statements.track = 'top';
|
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
EXPLAIN (COSTS OFF) CREATE TEMPORARY TABLE pgss_explain_ctas AS SELECT 1;
|
|
|
|
SELECT toplevel, calls, query FROM pg_stat_statements
|
|
|
|
ORDER BY query COLLATE "C";
|
|
|
|
|
|
|
|
-- DECLARE CURSOR, all-level tracking.
|
|
|
|
SET pg_stat_statements.track = 'all';
|
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
BEGIN;
|
|
|
|
DECLARE FOOCUR CURSOR FOR SELECT * from stats_track_tab;
|
|
|
|
FETCH FORWARD 1 FROM foocur;
|
|
|
|
CLOSE foocur;
|
|
|
|
COMMIT;
|
|
|
|
SELECT toplevel, calls, query FROM pg_stat_statements
|
|
|
|
ORDER BY query COLLATE "C";
|
|
|
|
|
|
|
|
-- DECLARE CURSOR, top-level tracking.
|
|
|
|
SET pg_stat_statements.track = 'top';
|
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
BEGIN;
|
|
|
|
DECLARE FOOCUR CURSOR FOR SELECT * FROM stats_track_tab;
|
|
|
|
FETCH FORWARD 1 FROM foocur;
|
|
|
|
CLOSE foocur;
|
|
|
|
COMMIT;
|
|
|
|
SELECT toplevel, calls, query FROM pg_stat_statements
|
|
|
|
ORDER BY query COLLATE "C";
|
|
|
|
|
|
|
|
-- COPY - all-level tracking.
|
|
|
|
SET pg_stat_statements.track = 'all';
|
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
COPY (SELECT 1) TO stdout;
|
|
|
|
COPY (SELECT 1 UNION SELECT 2) TO stdout;
|
|
|
|
COPY (MERGE INTO stats_track_tab USING (SELECT 1 id) ON x = id
|
|
|
|
WHEN MATCHED THEN UPDATE SET x = id
|
|
|
|
WHEN NOT MATCHED THEN INSERT (x) VALUES (id) RETURNING x) TO stdout;
|
|
|
|
COPY (INSERT INTO stats_track_tab (x) VALUES (1) RETURNING x) TO stdout;
|
|
|
|
COPY (UPDATE stats_track_tab SET x = 2 WHERE x = 1 RETURNING x) TO stdout;
|
|
|
|
COPY (DELETE FROM stats_track_tab WHERE x = 2 RETURNING x) TO stdout;
|
|
|
|
SELECT toplevel, calls, query FROM pg_stat_statements
|
|
|
|
ORDER BY query COLLATE "C";
|
|
|
|
|
|
|
|
-- COPY - top-level tracking.
|
|
|
|
SET pg_stat_statements.track = 'top';
|
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
COPY (SELECT 1) TO stdout;
|
|
|
|
COPY (SELECT 1 UNION SELECT 2) TO stdout;
|
|
|
|
COPY (MERGE INTO stats_track_tab USING (SELECT 1 id) ON x = id
|
|
|
|
WHEN MATCHED THEN UPDATE SET x = id
|
|
|
|
WHEN NOT MATCHED THEN INSERT (x) VALUES (id) RETURNING x) TO stdout;
|
|
|
|
COPY (INSERT INTO stats_track_tab (x) VALUES (1) RETURNING x) TO stdout;
|
|
|
|
COPY (UPDATE stats_track_tab SET x = 2 WHERE x = 1 RETURNING x) TO stdout;
|
|
|
|
COPY (DELETE FROM stats_track_tab WHERE x = 2 RETURNING x) TO stdout;
|
|
|
|
SELECT toplevel, calls, query FROM pg_stat_statements
|
|
|
|
ORDER BY query COLLATE "C";
|
|
|
|
|
Fix some issues with tracking nesting level in pg_stat_statements.
When we decide that we don't want to track execution time of a
specific planner or ProcessUtility call, we still have to increment
the nesting depth, or we'll make the wrong determination of whether
we are at top level when considering nested statements. (PREPARE
and EXECUTE are exceptions, for reasons explained in the code.)
Counting planner nesting depth separately from executor nesting depth
was a mistake: it causes us to make the wrong determination of whether
we are at top level when considering nested statements that get
executed during planning (as a result of constant-folding of
functions, for example). Merge those counters into one.
In passing, get rid of the PGSS_HANDLED_UTILITY macro in favor of
explicitly listing statement types. It seems somewhat coincidental
that PREPARE and EXECUTE are handled alike in each of the places where
that was used: the reasoning tends to be different for each one.
Thus, the macro seems as likely to encourage future bugs as prevent
them, since it's quite unclear whether any future statement type that
might need special-casing here would also need the same choices at
each spot.
Sergei Kornilov, Julien Rouhaud, and Tom Lane, per bug #17552 from
Maxim Boguk. This is pretty clearly a bug fix, but it's also a
behavioral change that might surprise somebody, so no back-patch.
Discussion: https://postgr.es/m/17552-213b534c56ab5d02@postgresql.org
2023-11-08 12:01:28 -05:00
|
|
|
-- DO block - top-level tracking without utility.
|
|
|
|
SET pg_stat_statements.track = 'top';
|
|
|
|
SET pg_stat_statements.track_utility = FALSE;
|
2023-11-27 02:50:59 +02:00
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
Fix some issues with tracking nesting level in pg_stat_statements.
When we decide that we don't want to track execution time of a
specific planner or ProcessUtility call, we still have to increment
the nesting depth, or we'll make the wrong determination of whether
we are at top level when considering nested statements. (PREPARE
and EXECUTE are exceptions, for reasons explained in the code.)
Counting planner nesting depth separately from executor nesting depth
was a mistake: it causes us to make the wrong determination of whether
we are at top level when considering nested statements that get
executed during planning (as a result of constant-folding of
functions, for example). Merge those counters into one.
In passing, get rid of the PGSS_HANDLED_UTILITY macro in favor of
explicitly listing statement types. It seems somewhat coincidental
that PREPARE and EXECUTE are handled alike in each of the places where
that was used: the reasoning tends to be different for each one.
Thus, the macro seems as likely to encourage future bugs as prevent
them, since it's quite unclear whether any future statement type that
might need special-casing here would also need the same choices at
each spot.
Sergei Kornilov, Julien Rouhaud, and Tom Lane, per bug #17552 from
Maxim Boguk. This is pretty clearly a bug fix, but it's also a
behavioral change that might surprise somebody, so no back-patch.
Discussion: https://postgr.es/m/17552-213b534c56ab5d02@postgresql.org
2023-11-08 12:01:28 -05:00
|
|
|
DELETE FROM stats_track_tab;
|
|
|
|
DO $$
|
|
|
|
BEGIN
|
|
|
|
DELETE FROM stats_track_tab;
|
|
|
|
END; $$;
|
|
|
|
DO LANGUAGE plpgsql $$
|
|
|
|
BEGIN
|
|
|
|
-- this is a SELECT
|
|
|
|
PERFORM 'hello world'::TEXT;
|
|
|
|
END; $$;
|
|
|
|
SELECT toplevel, calls, query FROM pg_stat_statements
|
|
|
|
ORDER BY query COLLATE "C", toplevel;
|
|
|
|
|
|
|
|
-- DO block - all-level tracking without utility.
|
|
|
|
SET pg_stat_statements.track = 'all';
|
2023-11-27 02:50:59 +02:00
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
Fix some issues with tracking nesting level in pg_stat_statements.
When we decide that we don't want to track execution time of a
specific planner or ProcessUtility call, we still have to increment
the nesting depth, or we'll make the wrong determination of whether
we are at top level when considering nested statements. (PREPARE
and EXECUTE are exceptions, for reasons explained in the code.)
Counting planner nesting depth separately from executor nesting depth
was a mistake: it causes us to make the wrong determination of whether
we are at top level when considering nested statements that get
executed during planning (as a result of constant-folding of
functions, for example). Merge those counters into one.
In passing, get rid of the PGSS_HANDLED_UTILITY macro in favor of
explicitly listing statement types. It seems somewhat coincidental
that PREPARE and EXECUTE are handled alike in each of the places where
that was used: the reasoning tends to be different for each one.
Thus, the macro seems as likely to encourage future bugs as prevent
them, since it's quite unclear whether any future statement type that
might need special-casing here would also need the same choices at
each spot.
Sergei Kornilov, Julien Rouhaud, and Tom Lane, per bug #17552 from
Maxim Boguk. This is pretty clearly a bug fix, but it's also a
behavioral change that might surprise somebody, so no back-patch.
Discussion: https://postgr.es/m/17552-213b534c56ab5d02@postgresql.org
2023-11-08 12:01:28 -05:00
|
|
|
DELETE FROM stats_track_tab;
|
|
|
|
DO $$
|
|
|
|
BEGIN
|
|
|
|
DELETE FROM stats_track_tab;
|
|
|
|
END; $$;
|
|
|
|
DO LANGUAGE plpgsql $$
|
|
|
|
BEGIN
|
|
|
|
-- this is a SELECT
|
|
|
|
PERFORM 'hello world'::TEXT;
|
|
|
|
END; $$;
|
|
|
|
SELECT toplevel, calls, query FROM pg_stat_statements
|
|
|
|
ORDER BY query COLLATE "C", toplevel;
|
|
|
|
|
Fix regression with location calculation of nested statements
The statement location calculated for some nested query cases was wrong
when multiple queries are sent as a single string, these being separated
by semicolons. As pointed by Sami Imseih, the location calculation was
incorrect when the last query of nested statement with multiple queries
does **NOT** finish with a semicolon for the last statement. In this
case, the statement length tracked by RawStmt is 0, which is equivalent
to say that the string should be used until its end. The code
previously discarded this case entirely, causing the location to remain
at 0, the same as pointing at the beginning of the string. This caused
pg_stat_statements to store incorrect query strings.
This issue has been introduced in 499edb09741b. I have looked at the
diffs generated by pgaudit back then, and noticed the difference
generated for this nested query case, but I have missed the point that
it was an actual regression with an existing case. A test case is added
in pg_stat_statements to provide some coverage, restoring the pre-17
behavior for the calculation of the query locations. Special thanks to
David Steele, who, through an analysis of the test diffs generated by
pgaudit with the new v18 logic, has poked me about the fact that my
original analysis of the matter was wrong.
The test output of pg_overexplain is updated to reflect the new logic,
as the new locations refer to the beginning of the argument passed to
the function explain_filter(). When the module was introduced in
8d5ceb113e3f, which was after 499edb09741b (for the new calculation
method), the locations of the test were not actually right: the plan
generated for the query string given in input of the function pointed to
the top-level query, not the nested one.
Reported-by: David Steele <david@pgbackrest.org>
Author: Michael Paquier <michael@paquier.xyz>
Reviewed-by: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>
Reviewed-by: Jian He <jian.universality@gmail.com>
Reviewed-by: Sami Imseih <samimseih@gmail.com>
Reviewed-by: David Steele <david@pgbackrest.org>
Discussion: https://postgr.es/m/844a3b38-bbf1-4fb2-9fd6-f58c35c09917@pgbackrest.org
2025-05-21 10:22:12 +09:00
|
|
|
-- DO block --- multiple inner queries with separators
|
|
|
|
SET pg_stat_statements.track = 'all';
|
|
|
|
SET pg_stat_statements.track_utility = TRUE;
|
|
|
|
CREATE TABLE pgss_do_util_tab_1 (a int);
|
|
|
|
CREATE TABLE pgss_do_util_tab_2 (a int);
|
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
DO $$
|
|
|
|
DECLARE BEGIN
|
|
|
|
EXECUTE 'CREATE TABLE pgss_do_table (id INT); DROP TABLE pgss_do_table';
|
|
|
|
EXECUTE 'SELECT a FROM pgss_do_util_tab_1; SELECT a FROM pgss_do_util_tab_2';
|
|
|
|
END $$;
|
|
|
|
SELECT toplevel, calls, rows, query FROM pg_stat_statements
|
|
|
|
WHERE toplevel IS FALSE
|
|
|
|
ORDER BY query COLLATE "C";
|
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
|
|
|
-- Note the extra semicolon at the end of the query.
|
|
|
|
DO $$
|
|
|
|
DECLARE BEGIN
|
|
|
|
EXECUTE 'CREATE TABLE pgss_do_table (id INT); DROP TABLE pgss_do_table;';
|
|
|
|
EXECUTE 'SELECT a FROM pgss_do_util_tab_1; SELECT a FROM pgss_do_util_tab_2;';
|
|
|
|
END $$;
|
|
|
|
SELECT toplevel, calls, rows, query FROM pg_stat_statements
|
|
|
|
WHERE toplevel IS FALSE
|
|
|
|
ORDER BY query COLLATE "C";
|
|
|
|
DROP TABLE pgss_do_util_tab_1, pgss_do_util_tab_2;
|
|
|
|
|
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 09:28:29 +09:00
|
|
|
-- PL/pgSQL function - top-level tracking.
|
|
|
|
SET pg_stat_statements.track = 'top';
|
|
|
|
SET pg_stat_statements.track_utility = FALSE;
|
2023-11-27 02:50:59 +02: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 09:28:29 +09:00
|
|
|
CREATE FUNCTION PLUS_TWO(i INTEGER) RETURNS INTEGER AS $$
|
|
|
|
DECLARE
|
|
|
|
r INTEGER;
|
|
|
|
BEGIN
|
|
|
|
SELECT (i + 1 + 1.0)::INTEGER INTO r;
|
|
|
|
RETURN r;
|
|
|
|
END; $$ LANGUAGE plpgsql;
|
|
|
|
|
|
|
|
SELECT PLUS_TWO(3);
|
|
|
|
SELECT PLUS_TWO(7);
|
|
|
|
|
|
|
|
-- SQL function --- use LIMIT to keep it from being inlined
|
|
|
|
CREATE FUNCTION PLUS_ONE(i INTEGER) RETURNS INTEGER AS
|
|
|
|
$$ SELECT (i + 1.0)::INTEGER LIMIT 1 $$ LANGUAGE SQL;
|
|
|
|
|
|
|
|
SELECT PLUS_ONE(8);
|
|
|
|
SELECT PLUS_ONE(10);
|
|
|
|
|
|
|
|
SELECT calls, rows, query FROM pg_stat_statements ORDER BY query COLLATE "C";
|
|
|
|
|
Fix some issues with tracking nesting level in pg_stat_statements.
When we decide that we don't want to track execution time of a
specific planner or ProcessUtility call, we still have to increment
the nesting depth, or we'll make the wrong determination of whether
we are at top level when considering nested statements. (PREPARE
and EXECUTE are exceptions, for reasons explained in the code.)
Counting planner nesting depth separately from executor nesting depth
was a mistake: it causes us to make the wrong determination of whether
we are at top level when considering nested statements that get
executed during planning (as a result of constant-folding of
functions, for example). Merge those counters into one.
In passing, get rid of the PGSS_HANDLED_UTILITY macro in favor of
explicitly listing statement types. It seems somewhat coincidental
that PREPARE and EXECUTE are handled alike in each of the places where
that was used: the reasoning tends to be different for each one.
Thus, the macro seems as likely to encourage future bugs as prevent
them, since it's quite unclear whether any future statement type that
might need special-casing here would also need the same choices at
each spot.
Sergei Kornilov, Julien Rouhaud, and Tom Lane, per bug #17552 from
Maxim Boguk. This is pretty clearly a bug fix, but it's also a
behavioral change that might surprise somebody, so no back-patch.
Discussion: https://postgr.es/m/17552-213b534c56ab5d02@postgresql.org
2023-11-08 12:01:28 -05:00
|
|
|
-- immutable SQL function --- can be executed at plan time
|
|
|
|
CREATE FUNCTION PLUS_THREE(i INTEGER) RETURNS INTEGER AS
|
|
|
|
$$ SELECT i + 3 LIMIT 1 $$ IMMUTABLE LANGUAGE SQL;
|
|
|
|
|
|
|
|
SELECT PLUS_THREE(8);
|
|
|
|
SELECT PLUS_THREE(10);
|
|
|
|
|
|
|
|
SELECT toplevel, calls, rows, query FROM pg_stat_statements ORDER BY query COLLATE "C";
|
|
|
|
|
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 09:28:29 +09:00
|
|
|
-- PL/pgSQL function - all-level tracking.
|
|
|
|
SET pg_stat_statements.track = 'all';
|
2023-11-27 02:50:59 +02: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 09:28:29 +09:00
|
|
|
|
|
|
|
-- we drop and recreate the functions to avoid any caching funnies
|
|
|
|
DROP FUNCTION PLUS_ONE(INTEGER);
|
|
|
|
DROP FUNCTION PLUS_TWO(INTEGER);
|
Fix some issues with tracking nesting level in pg_stat_statements.
When we decide that we don't want to track execution time of a
specific planner or ProcessUtility call, we still have to increment
the nesting depth, or we'll make the wrong determination of whether
we are at top level when considering nested statements. (PREPARE
and EXECUTE are exceptions, for reasons explained in the code.)
Counting planner nesting depth separately from executor nesting depth
was a mistake: it causes us to make the wrong determination of whether
we are at top level when considering nested statements that get
executed during planning (as a result of constant-folding of
functions, for example). Merge those counters into one.
In passing, get rid of the PGSS_HANDLED_UTILITY macro in favor of
explicitly listing statement types. It seems somewhat coincidental
that PREPARE and EXECUTE are handled alike in each of the places where
that was used: the reasoning tends to be different for each one.
Thus, the macro seems as likely to encourage future bugs as prevent
them, since it's quite unclear whether any future statement type that
might need special-casing here would also need the same choices at
each spot.
Sergei Kornilov, Julien Rouhaud, and Tom Lane, per bug #17552 from
Maxim Boguk. This is pretty clearly a bug fix, but it's also a
behavioral change that might surprise somebody, so no back-patch.
Discussion: https://postgr.es/m/17552-213b534c56ab5d02@postgresql.org
2023-11-08 12:01:28 -05:00
|
|
|
DROP FUNCTION PLUS_THREE(INTEGER);
|
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 09:28:29 +09:00
|
|
|
|
|
|
|
-- PL/pgSQL function
|
|
|
|
CREATE FUNCTION PLUS_TWO(i INTEGER) RETURNS INTEGER AS $$
|
|
|
|
DECLARE
|
|
|
|
r INTEGER;
|
|
|
|
BEGIN
|
|
|
|
SELECT (i + 1 + 1.0)::INTEGER INTO r;
|
|
|
|
RETURN r;
|
|
|
|
END; $$ LANGUAGE plpgsql;
|
|
|
|
|
|
|
|
SELECT PLUS_TWO(-1);
|
|
|
|
SELECT PLUS_TWO(2);
|
|
|
|
|
|
|
|
-- SQL function --- use LIMIT to keep it from being inlined
|
|
|
|
CREATE FUNCTION PLUS_ONE(i INTEGER) RETURNS INTEGER AS
|
|
|
|
$$ SELECT (i + 1.0)::INTEGER LIMIT 1 $$ LANGUAGE SQL;
|
|
|
|
|
|
|
|
SELECT PLUS_ONE(3);
|
|
|
|
SELECT PLUS_ONE(1);
|
|
|
|
|
|
|
|
SELECT calls, rows, query FROM pg_stat_statements ORDER BY query COLLATE "C";
|
Fix some issues with tracking nesting level in pg_stat_statements.
When we decide that we don't want to track execution time of a
specific planner or ProcessUtility call, we still have to increment
the nesting depth, or we'll make the wrong determination of whether
we are at top level when considering nested statements. (PREPARE
and EXECUTE are exceptions, for reasons explained in the code.)
Counting planner nesting depth separately from executor nesting depth
was a mistake: it causes us to make the wrong determination of whether
we are at top level when considering nested statements that get
executed during planning (as a result of constant-folding of
functions, for example). Merge those counters into one.
In passing, get rid of the PGSS_HANDLED_UTILITY macro in favor of
explicitly listing statement types. It seems somewhat coincidental
that PREPARE and EXECUTE are handled alike in each of the places where
that was used: the reasoning tends to be different for each one.
Thus, the macro seems as likely to encourage future bugs as prevent
them, since it's quite unclear whether any future statement type that
might need special-casing here would also need the same choices at
each spot.
Sergei Kornilov, Julien Rouhaud, and Tom Lane, per bug #17552 from
Maxim Boguk. This is pretty clearly a bug fix, but it's also a
behavioral change that might surprise somebody, so no back-patch.
Discussion: https://postgr.es/m/17552-213b534c56ab5d02@postgresql.org
2023-11-08 12:01:28 -05:00
|
|
|
|
|
|
|
-- immutable SQL function --- can be executed at plan time
|
|
|
|
CREATE FUNCTION PLUS_THREE(i INTEGER) RETURNS INTEGER AS
|
|
|
|
$$ SELECT i + 3 LIMIT 1 $$ IMMUTABLE LANGUAGE SQL;
|
|
|
|
|
|
|
|
SELECT PLUS_THREE(8);
|
|
|
|
SELECT PLUS_THREE(10);
|
|
|
|
|
|
|
|
SELECT toplevel, calls, rows, query FROM pg_stat_statements ORDER BY query COLLATE "C";
|
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 09:28:29 +09:00
|
|
|
|
|
|
|
--
|
|
|
|
-- pg_stat_statements.track = none
|
|
|
|
--
|
|
|
|
SET pg_stat_statements.track = 'none';
|
2023-11-27 02:50:59 +02: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 09:28:29 +09:00
|
|
|
|
|
|
|
SELECT 1 AS "one";
|
|
|
|
SELECT 1 + 1 AS "two";
|
|
|
|
|
|
|
|
SELECT calls, rows, query FROM pg_stat_statements ORDER BY query COLLATE "C";
|
2023-11-27 02:50:59 +02:00
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|