On 24.12.23 03:03, Michael Paquier wrote:
On Sat, Dec 23, 2023 at 03:18:01PM +0100, Peter Eisentraut wrote:
+/* LCOV_EXCL_START */
+PG_FUNCTION_INFO_V1(pg_stat_statements);
PG_FUNCTION_INFO_V1(pg_stat_statements_1_2);
+/* LCOV_EXCL_STOP */
The only reason why I've seen this used at the C level was to bump up
the coverage requirements because of some internal company projects.
I'm pretty sure to have proposed in the past at least one patch that
would make use of that, but it got rejected. It is not the only code
area that has a similar pattern. So why introducing that now?
What other code areas have similar patterns (meaning, extension entry
points for upgrade support that are not covered by currently available
extension installation files)?
That's a lot of bloat. This relies on pg_stat_statements.max's
default to be at 100.
The default is 5000. I set 100 explicitly in the configuration file for
the test.
- Use a DO block of a PL function, say with something like that to
ensure an amount of N queries? Say with something like that after
tweaking pg_stat_statements.track:
CREATE OR REPLACE FUNCTION create_tables(num_tables int)
RETURNS VOID AS
$func$
BEGIN
FOR i IN 1..num_tables LOOP
EXECUTE format('
CREATE TABLE IF NOT EXISTS %I (id int)', 't_' || i);
END LOOP;
END
$func$ LANGUAGE plpgsql;
I tried it like this first, but this doesn't register as separately
executed commands for pg_stat_statements.
- Switch the minimum to be around 40~50 in the local
pg_stat_statements.conf used for the regression tests.
100 is the hardcoded minimum for the setting.
+is( $node->safe_psql(
+ 'postgres',
+ "SELECT count(*) FROM pg_stat_statements WHERE query LIKE
'%t1%'"),
+ '2',
+ 'pg_stat_statements data kept across restart');
Checking that the contents match would be a bit more verbose than just
a count. One trick I've used in the patch is in
027_stream_regress.pl, where there is a query grouping the stats
depending on the beginning of the queries. Not exact, a bit more
verbose.
Yeah, this could be expanded a bit.
