Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tDD5c-00GlkC-SS for pgsql-hackers@arkaria.postgresql.org; Tue, 19 Nov 2024 01:31:37 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tDD5a-009RuZ-SL for pgsql-hackers@arkaria.postgresql.org; Tue, 19 Nov 2024 01:31:35 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tDD5Z-009RuQ-OZ for pgsql-hackers@lists.postgresql.org; Tue, 19 Nov 2024 01:31:35 +0000 Received: from mail.clear-code.com ([2401:2500:102:3037:153:126:203:179]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tDD5W-002fG2-G3 for pgsql-hackers@postgresql.org; Tue, 19 Nov 2024 01:31:33 +0000 Received: from localhost (unknown [IPv6:2404:7a80:9f01:f500:af1b:fa00:91d6:aaa9]) by mail.clear-code.com (Postfix) with ESMTPSA id E763AC06E3; Tue, 19 Nov 2024 10:31:18 +0900 (JST) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.clear-code.com E763AC06E3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=clear-code.com; s=default; t=1731979879; bh=sjchDV+CdaPcR76sVBz2bneXsuSF5m4owhgKbgVSHGE=; h=Date:To:Cc:Subject:From:In-Reply-To:References:From; b=N7rBMLvcQlb9/az4Pl8ItjTvt1ajIfpjZBfnVldRfR4PBx3pM9agfRwPy9JkivwdM yBCW2/oRlDRvb0F32pNv/TRchGnnZzitTN2gWVHlF3edZk2uoIXePLk925S79Cm5pW b+f30ZUILb+32KmTj/gtujjVyLtQOeSEIDKICSv8= Date: Tue, 19 Nov 2024 10:31:15 +0900 (JST) Message-Id: <20241119.103115.418773618386970482.kou@clear-code.com> To: sawada.mshk@gmail.com Cc: michael@paquier.xyz, pgsql-hackers@postgresql.org Subject: Re: Make COPY format extendable: Extract COPY TO format implementations From: Sutou Kouhei In-Reply-To: References: <20241114.161948.1677325020727842666.kou@clear-code.com> X-Mailer: Mew version 6.8 on Emacs 29.4 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: E763AC06E3 X-Rspamd-Server: mail.clear-code.com X-Spamd-Result: default: False [1.40 / 999.00]; MID_CONTAINS_FROM(1.00)[]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:2518, ipnet:2404:7a80::/29, country:JP]; FREEMAIL_TO(0.00)[gmail.com]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_NONE(0.00)[]; RCPT_COUNT_THREE(0.00)[3] X-Rspamd-Action: no action List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, In "Re: Make COPY format extendable: Extract COPY TO format implementations" on Mon, 18 Nov 2024 17:02:41 -0800, Masahiko Sawada wrote: > I have a question about v22. We use pg_attribute_always_inline for > some functions to avoid function call overheads. Applying it to > CopyToTextLikeOneRow() and CopyFromTextLikeOneRow() are legitimate as > we've discussed. But there are more function where the patch applied > it to: > > -bool > -NextCopyFromRawFields(CopyFromState cstate, char ***fields, int *nfields) > +static pg_attribute_always_inline bool > +NextCopyFromRawFields(CopyFromState cstate, char ***fields, int > *nfields, bool is_csv) > > -static bool > -CopyReadLineText(CopyFromState cstate) > +static pg_attribute_always_inline bool > +CopyReadLineText(CopyFromState cstate, bool is_csv) > > +static pg_attribute_always_inline void > +CopyToTextLikeSendEndOfRow(CopyToState cstate) > > I think it's out of scope of this patch even if these changes are > legitimate. Is there any reason for these changes? Yes for NextCopyFromRawFields() and CopyReadLineText(). No for CopyToTextLikeSendEndOfRow(). NextCopyFromRawFields() and CopyReadLineText() have "bool is_csv". So I think that we should use pg_attribute_always_inline (or inline) like CopyToTextLikeOneRow() and CopyFromTextLikeOneRow(). I think that it's not out of scope of this patch because it's a part of CopyToTextLikeOneRow() and CopyFromTextLikeOneRow() optimization. Note: The optimization is based on "bool is_csv" parameter and constant "true"/"false" argument function call. If we can inline this function call, all "if (is_csv)" checks in the function are removed. pg_attribute_always_inline (or inline) for CopyToTextLikeSendEndOfRow() is out of scope of this patch. You're right. I think that inlining CopyToTextLikeSendEndOfRow() is better because it's called per row. But it's not related to the optimization. Should I create a new patch set without pg_attribute_always_inline/inline for CopyToTextLikeSendEndOfRow()? Or could you remove it when you push? Thanks, -- kou