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
|
|
|
--
|
|
|
|
-- Cursors
|
|
|
|
--
|
|
|
|
|
|
|
|
-- 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;
|
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
|
|
|
|
|
|
|
-- DECLARE
|
|
|
|
-- SELECT is normalized.
|
|
|
|
DECLARE cursor_stats_1 CURSOR WITH HOLD FOR SELECT 1;
|
|
|
|
CLOSE cursor_stats_1;
|
|
|
|
DECLARE cursor_stats_1 CURSOR WITH HOLD FOR SELECT 2;
|
|
|
|
CLOSE cursor_stats_1;
|
|
|
|
|
|
|
|
SELECT calls, rows, query FROM pg_stat_statements ORDER BY query COLLATE "C";
|
|
|
|
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
|
|
|
|
|
|
|
-- FETCH
|
|
|
|
BEGIN;
|
|
|
|
DECLARE cursor_stats_1 CURSOR WITH HOLD FOR SELECT 2;
|
|
|
|
DECLARE cursor_stats_2 CURSOR WITH HOLD FOR SELECT 3;
|
|
|
|
FETCH 1 IN cursor_stats_1;
|
|
|
|
FETCH 1 IN cursor_stats_2;
|
|
|
|
CLOSE cursor_stats_1;
|
|
|
|
CLOSE cursor_stats_2;
|
|
|
|
COMMIT;
|
|
|
|
|
|
|
|
SELECT calls, rows, query FROM pg_stat_statements ORDER BY query COLLATE "C";
|
|
|
|
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
|
Show sizes of FETCH queries as constants in pg_stat_statements
Prior to this patch, every FETCH call would generate a unique queryId
with a different size specified. Depending on the workloads, this could
lead to a significant bloat in pg_stat_statements, as repeatedly calling
a specific cursor would result in a new queryId each time. For example,
FETCH 1 c1; and FETCH 2 c1; would produce different queryIds.
This patch improves the situation by normalizing the fetch size, so as
semantically similar statements generate the same queryId. As a result,
statements like the below, which differ syntactically but have the same
effect, will now share a single queryId:
FETCH FROM c1
FETCH NEXT c1
FETCH 1 c1
In order to do a normalization based on the keyword used in FETCH,
FetchStmt is tweaked with a new FetchDirectionKeywords. This matters
for "howMany", which could be set to a negative value depending on the
direction, and we want to normalize the queries with enough information
about the direction keywords provided, including RELATIVE, ABSOLUTE or
all the ALL variants.
Author: Sami Imseih <samimseih@gmail.com>
Discussion: https://postgr.es/m/CAA5RZ0tA6LbHCg2qSS+KuM850BZC_+ZgHV7Ug6BXw22TNyF+MA@mail.gmail.com
3 months ago
|
|
|
|
|
|
|
-- Normalization of FETCH statements
|
|
|
|
BEGIN;
|
|
|
|
DECLARE pgss_cursor CURSOR FOR SELECT FROM generate_series(1, 10);
|
|
|
|
-- implicit directions
|
|
|
|
FETCH pgss_cursor;
|
|
|
|
FETCH 1 pgss_cursor;
|
|
|
|
FETCH 2 pgss_cursor;
|
|
|
|
FETCH -1 pgss_cursor;
|
|
|
|
-- explicit NEXT
|
|
|
|
FETCH NEXT pgss_cursor;
|
|
|
|
-- explicit PRIOR
|
|
|
|
FETCH PRIOR pgss_cursor;
|
|
|
|
-- explicit FIRST
|
|
|
|
FETCH FIRST pgss_cursor;
|
|
|
|
-- explicit LAST
|
|
|
|
FETCH LAST pgss_cursor;
|
|
|
|
-- explicit ABSOLUTE
|
|
|
|
FETCH ABSOLUTE 1 pgss_cursor;
|
|
|
|
FETCH ABSOLUTE 2 pgss_cursor;
|
|
|
|
FETCH ABSOLUTE -1 pgss_cursor;
|
|
|
|
-- explicit RELATIVE
|
|
|
|
FETCH RELATIVE 1 pgss_cursor;
|
|
|
|
FETCH RELATIVE 2 pgss_cursor;
|
|
|
|
FETCH RELATIVE -1 pgss_cursor;
|
|
|
|
-- explicit FORWARD
|
|
|
|
FETCH ALL pgss_cursor;
|
|
|
|
-- explicit FORWARD ALL
|
|
|
|
FETCH FORWARD ALL pgss_cursor;
|
|
|
|
-- explicit FETCH FORWARD
|
|
|
|
FETCH FORWARD pgss_cursor;
|
|
|
|
FETCH FORWARD 1 pgss_cursor;
|
|
|
|
FETCH FORWARD 2 pgss_cursor;
|
|
|
|
FETCH FORWARD -1 pgss_cursor;
|
|
|
|
-- explicit FETCH BACKWARD
|
|
|
|
FETCH BACKWARD pgss_cursor;
|
|
|
|
FETCH BACKWARD 1 pgss_cursor;
|
|
|
|
FETCH BACKWARD 2 pgss_cursor;
|
|
|
|
FETCH BACKWARD -1 pgss_cursor;
|
|
|
|
-- explicit BACKWARD ALL
|
|
|
|
FETCH BACKWARD ALL pgss_cursor;
|
|
|
|
COMMIT;
|
|
|
|
SELECT calls, query FROM pg_stat_statements ORDER BY query COLLATE "C";
|