Re: pg_stat_statements: more test coverage

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_stat_statements: more test coverage
Date: 2023-12-26 21:03:20
Message-ID: 432813c3-ec86-4212-aebb-fe8eb00b0b8d@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Vik Fearing 2023-12-26 21:45:31 Re: A tiny improvement of psql
Previous Message Peter Eisentraut 2023-12-26 20:38:47 Re: No LINGUAS file yet for pg_combinebackup