Message-ID: <9b2133f6-7bf6-07c4-e896-7a8d9a629d56@oss.nttdata.com>
Date: Thu, 22 Sep 2022 01:07:33 +0900
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.13.0
Subject: Re: Query Jumbling for CALL and SET utility statements
Content-Language: en-US
To: "Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com>,
 Julien Rouhaud <rjuju123@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>,
 Jeremy Schneider <schnjere@amazon.com>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
 Pavel Stehule <pavel.stehule@gmail.com>, Andres Freund <andres@anarazel.de>,
 "Imseih (AWS), Sami" <simseih@amazon.com>
References: <46ca04f9-1e37-c862-9a28-c5dffaee412f@amazon.com>
 <20220831190604.l2luuhj3xkau7dvk@awork3.anarazel.de>
 <e43a0e02-4ef4-d510-a00a-cf39d2a9df19@amazon.com>
 <cbd28368-a5ae-f141-4c3f-28ba9f608ba0@amazon.com>
 <BBB9A13D-BBE2-44A4-9CA7-6E189120E5A2@amazon.com>
 <09c04aba-7f12-e524-20f7-3f92c1479fdf@amazon.com>
 <9aee54f2-5cc1-5b64-1f73-6961932e7bd2@amazon.com>
 <Yxl8R8mAUG2vqAcC@paquier.xyz> <20220908065012.l3bd2np7wj52cxco@jrouhaud>
 <c65f1c67-bae4-9658-9206-f11e9c6f7d11@amazon.com>
 <20220908112919.2ytxpkitiw6lt2u6@jrouhaud>
 <a16d303f-39ad-319c-18ff-85b78b106fe1@amazon.com>
 <a0d66747-3f8c-5346-5baa-61299e2cb4da@amazon.com>
 <37d32e91-4a08-afaf-a3a8-fd0578e4db50@oss.nttdata.com>
 <706ee610-4297-453b-f6f2-1e79161414f6@gmail.com>
 <6d0d8a57-0e9c-7fcb-5072-aae544dafa5c@gmail.com>
From: Fujii Masao <masao.fujii@oss.nttdata.com>
In-Reply-To: <6d0d8a57-0e9c-7fcb-5072-aae544dafa5c@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/9b2133f6-7bf6-07c4-e896-7a8d9a629d56%40oss.nttdata.com>
Precedence: bulk


On 2022/09/19 15:29, Drouvot, Bertrand wrote:
> Please find attached v6 taking care of the remarks mentioned above.

Thanks for updating the patch!

+SET pg_stat_statements.track_utility = TRUE;
+
+-- PL/pgSQL procedure and pg_stat_statements.track = all
+-- we drop and recreate the procedures to avoid any caching funnies
+SET pg_stat_statements.track_utility = FALSE;

Could you tell me why track_utility is enabled just before it's disabled?

Could you tell me what actually happens if we don't drop and
recreate the procedures? I'd like to know what "any caching funnies" are.

+SELECT pg_stat_statements_reset();
+CALL MINUS_TWO(3);
+CALL MINUS_TWO(7);
+CALL SUM_TWO(3, 8);
+CALL SUM_TWO(7, 5);
+
+SELECT query, calls, rows FROM pg_stat_statements ORDER BY query COLLATE "C";

This test set for the procedures is executed with the following
four conditions, respectively. Do we really need all of these tests?

track = top, track_utility = true
track = top, track_utility = false
track = all, track_utility = true
track = all, track_utility = false

+begin;
+prepare transaction 'tx1';
+insert into test_tx values (1);
+commit prepared 'tx1';

The test set of 2PC commands is also executed with track_utility = on
and off, respectively. But why do we need to run that test when
track_utility = off?

-	if (query->utilityStmt)
+	if (query->utilityStmt && !jstate)
  	{
  		if (pgss_track_utility && !PGSS_HANDLED_UTILITY(query->utilityStmt))

"pgss_track_utility" should be
"pgss_track_utility || FORCE_TRACK_UTILITY(parsetree)" theoretically?

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION