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.
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 |