Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kXgre-000301-5L for pgsql-hackers@arkaria.postgresql.org; Wed, 28 Oct 2020 08:31:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kXgrd-0007Ve-2d for pgsql-hackers@arkaria.postgresql.org; Wed, 28 Oct 2020 08:31:25 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kXgrc-0007VX-SF for pgsql-hackers@lists.postgresql.org; Wed, 28 Oct 2020 08:31:24 +0000 Received: from oss.nttdata.com ([49.212.34.109]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kXgrW-0001ce-EX for pgsql-hackers@lists.postgresql.org; Wed, 28 Oct 2020 08:31:23 +0000 Received: from oss.nttdata.com (localhost [127.0.0.1]) by oss.nttdata.com (Postfix) with ESMTP id D24A262311; Wed, 28 Oct 2020 17:31:14 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.102.3 at oss.nttdata.com MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 28 Oct 2020 17:31:14 +0900 From: seinoyu To: Fujii Masao Cc: pgsql-hackers@lists.postgresql.org Subject: Re: [PATCH] Add features to pg_stat_statements In-Reply-To: <369018a4-746c-6914-4983-1b79aa9fdd37@oss.nttdata.com> References: <0d9f1107772cf5c3f954e985464c7298@oss.nttdata.com> <160250511275.1171.7692218521107860164.pgcf@coridan.postgresql.org> <369018a4-746c-6914-4983-1b79aa9fdd37@oss.nttdata.com> Message-ID: <4ab1bf5ab895d44ff0a3b3d06d1f85b2@oss.nttdata.com> X-Sender: seinoyu@oss.nttdata.com User-Agent: Roundcube Webmail/1.1.9 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk 2020-10-22 01:31 に Fujii Masao さんは書きました: > On 2020/10/12 21:18, Yuki Seino wrote: >> The following review has been posted through the commitfest >> application: >> make installcheck-world: tested, passed >> Implements feature: tested, passed >> Spec compliant: tested, passed >> Documentation: tested, passed >> >> The patch applies cleanly and looks fine to me. It's a small detail, >> However wouldn't it be better if the following changes were made. >> >> 1.There are unnecessary difference lines 707 and 863 in >> "pg_stat_statements.c". >> 2.There is no comment on "slock_t mutex" in "struct pgssCtlCounter" in >> "pg_stat_statements.c". >> 3."update_ctl" and "reset_ctl" are generic and illegible name.You >> might want to rename it something like "pgss_ctl_update". >> 4.To improve the readability of the source, why not change the >> function declaration option in "pg_stat_statements_ctl" from >> "AS 'MODULE_PATHNAME'" to "AS 'MODULE_PATHNAME', >> 'pg_stat_statements_ctl'"? in "pg_stat_statements--1.8--1.9.sql". >> >> The new status of this patch is: Waiting on Author > > Here are other comments from me. > > -DATA = pg_stat_statements--1.4.sql \ > +DATA = pg_stat_statements--1.4.sql pg_stat_statements--1.8--1.9.sql\ > > One space character needs to be added just before the character "\". > > +--- Define pg_stat_statements_ctl > > ISTM that this is not good name. > What about pg_stat_statements_info, _stats, _activity or something? > > + OUT dealloc integer, > > The type of "dealloc" should be bigint, instead? > > + OUT last_dealloc TIMESTAMP WITH TIME ZONE > > Is this information really useful? > If there is no valid use case for this, I'd like to drop it. > Thought? > > +LANGUAGE C STRICT VOLATILE PARALLEL SAFE; > > There are two space characters just after "LANGUAGE". > One space character should be removed from there. > > +CREATE VIEW pg_stat_statements_ctl AS > + SELECT * FROM pg_stat_statements_ctl(); > > If we rename the function, this view name also should be changed. > > +GRANT SELECT ON pg_stat_statements TO PUBLIC; > > "pg_stat_statements" should be "pg_stat_statement_xxx"? > > Regards, Thanks for the comment, Fujii-san. I will post the patch again in the future to reflect your and my points. However, let me confirm the following. > Is this information really useful? > If there is no valid use case for this, I'd like to drop it. > Thought? I thought it would be easy for users to see at a glance that if there is a case I assumed, if the last modified date and time is old, there is no need to adjust at all, and if the last modified date and time is recent, it would be easy for users to understand that the parameters need to be adjusted. What do you think? Regards, Seino Yuki