summaryrefslogtreecommitdiff
path: root/contrib/pg_stat_statements/sql
diff options
context:
space:
mode:
authorMichael Paquier <michael@paquier.xyz>2024-10-24 09:28:51 +0900
committerMichael Paquier <michael@paquier.xyz>2024-10-24 09:29:54 +0900
commit499edb09741b8fad2de038361fb342aae6e6007f (patch)
tree03e40bbc6cf03c6f6442525865391e2b7066de57 /contrib/pg_stat_statements/sql
parent4b096c67e0eed81e287094b9692fff72b9ea3eef (diff)
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
Diffstat (limited to 'contrib/pg_stat_statements/sql')
-rw-r--r--contrib/pg_stat_statements/sql/planning.sql4
1 files changed, 2 insertions, 2 deletions
diff --git a/contrib/pg_stat_statements/sql/planning.sql b/contrib/pg_stat_statements/sql/planning.sql
index 46f5d9b951c..9cfe206b3b0 100644
--- a/contrib/pg_stat_statements/sql/planning.sql
+++ b/contrib/pg_stat_statements/sql/planning.sql
@@ -20,11 +20,11 @@ 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";
+ WHERE query NOT LIKE 'SELECT COUNT%' 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";
+ WHERE query LIKE 'SELECT COUNT%' ORDER BY query COLLATE "C";
-- Cleanup
DROP TABLE stats_plan_test;