Re: Normalization of utility queries in pg_stat_statements - Mailing list pgsql-hackers

From Drouvot, Bertrand
Subject Re: Normalization of utility queries in pg_stat_statements
Date
Msg-id 14965f63-6d78-45ff-d029-daafe8eddb40@gmail.com
Whole thread Raw
In response to Re: Normalization of utility queries in pg_stat_statements  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Normalization of utility queries in pg_stat_statements
List pgsql-hackers
Hi,

On 2/17/23 3:35 AM, Michael Paquier wrote:
> On Thu, Feb 16, 2023 at 10:55:32AM +0100, Drouvot, Bertrand wrote:
>> In the new pg_stat_statements.sql? That way pg_stat_statements.sql would always behave
>> with default values for those (currently we are setting both of them as non default).
>>
>> Then, with the default values in place, if we feel that some tests
>> are missing we could add them in > utility.sql or planning.sql
>> accordingly.
> 
> I am not sure about this part, TBH, so I have left these as they are.
> 
> Anyway, while having a second look at that, I have noticed that it is
> possible to extract as an independent piece all the tests related to
> level tracking.  Things are worse than I thought initially, actually,
> because we had test scenarios mixing planning and level tracking, but
> the tests don't care about measuring plans at all, see around FETCH
> FORWARD, meaning that queries on the table pg_stat_statements have
> just been copy-pasted around for the last few years.  There were more
> tests that used "test" for a table name ;)
> 
> I have been pondering about this part, and the tracking matters for DO
> blocks and PL functions, so I have moved all these cases into a new,
> separate file.  There is a bit more that can be done, for WAL tracking
> and roles near the end of pg_stat_statements.sql, but I have left that
> out for now.  I have checked the output of the tests before and after
> the refactoring for quite a bit of time, and the outputs match so
> there is no loss of coverage.
> 
> 0001 looks quite committable at this stage, and that's independent on
> the rest.  At the end this patch creates four new test files that are
> extended in the next patches: utility, planning, track and cleanup.
> 

Thanks! LGTM.

>> 0002:
>>
>> Produces:
>> v2-0002-Add-more-test-for-utility-queries-in-pg_stat_stat.patch:834: trailing whitespace.
>> CREATE VIEW view_stats_1 AS
>> v2-0002-Add-more-test-for-utility-queries-in-pg_stat_stat.patch:838: trailing whitespace.
>> CREATE VIEW view_stats_1 AS
>> warning: 2 lines add whitespace errors.
> 
> Thanks, fixed.
> 

Thanks!

>> +-- SET TRANSACTION ISOLATION
>> +BEGIN;
>> +SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
>> +SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
>> +SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
>>
>> What about adding things like "SET SESSION CHARACTERISTICS AS
>> TRANSACTION..." too?
> 
> That's a good idea.  It is again one of these fancy cases, better to
> keep a track of them in the long-term..
> 

Right.

002 LGTM.

>> 0003 and 0004:
>> Thanks for keeping 0003 that's useful to see the impact of A_Const normalization.
>>
>> Looking at the diff they produce, I also do think that 0004 is what
>> could be done for PG16.
> 
> I am wondering if others have an opinion to share about that, but,
> yes, 0004 seems enough to begin with.  We could always study more
> normalization areas in future releases, taking it slowly.

Agree.

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Yuya Watari
Date:
Subject: Re: [PoC] Reducing planning time when tables have many partitions
Next
From: Katsuragi Yuta
Date:
Subject: Re: [Proposal] Add foreign-server health checks infrastructure