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 1sjqXM-004hzd-Il for pgsql-hackers@arkaria.postgresql.org; Fri, 30 Aug 2024 01:34:53 +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 1sjqXJ-00BSAk-Kd for pgsql-hackers@arkaria.postgresql.org; Fri, 30 Aug 2024 01:34:50 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sjqXI-00BS6l-VJ for pgsql-hackers@lists.postgresql.org; Fri, 30 Aug 2024 01:34:49 +0000 Received: from m16.mail.163.com ([117.135.210.2]) by makus.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sjqXC-0026Jg-PF for pgsql-hackers@postgresql.org; Fri, 30 Aug 2024 01:34:46 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:Subject:Date:Message-ID:MIME-Version: Content-Type; bh=x7/SGag2tavxgVfXztDuVB04N4NqHGlGylcIFDlUq1A=; b=Z54CbDZrKXIIlsj5a5JJCWrngP1FstBSOzzKWybVT5sLVo2cgsutTW0FC+iUJS o/mJoB34w/RxS+j3KgWUA1PbloD04S67cHeR8PXkYJI4Gdb597PdFtZ3Cezx0Mzj TBbIgnvsjjrNQKfsrPa4hbZul4PrLpwxklGzO4o/J2AVU= Received: from lovely-coding (unknown [101.227.46.166]) by gzga-smtp-mta-g2-4 (Coremail) with SMTP id _____wDXL+yqIdFmzMLvAg--.51366S3; Fri, 30 Aug 2024 09:34:35 +0800 (CST) From: Andy Fan To: David Rowley Cc: pgsql-hackers , Tom Lane Subject: Re: Make printtup a bit faster In-Reply-To: (David Rowley's message of "Fri, 30 Aug 2024 13:13:37 +1200") References: <87wmjzfz0h.fsf@163.com> <87bk1aj2go.fsf@163.com> <877cbyizxp.fsf@163.com> Date: Fri, 30 Aug 2024 09:34:34 +0800 Message-ID: <8734mmiyj9.fsf@163.com> MIME-Version: 1.0 Content-Type: text/plain X-CM-TRANSID: _____wDXL+yqIdFmzMLvAg--.51366S3 X-Coremail-Antispam: 1Uf129KBjvJXoW7WFWftF4xZw18Jr4kZr1fJFb_yoW8Xr48pa yvkFyaqFykAw4Iywn2qw4FqF47ZrWSkr1Yq3Z0yry8Z3y5ZFnayFs8Ww4j934DGrn2krW0 va1FvF1UGa9Yva7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0zRrR6xUUUUU= X-Originating-IP: [101.227.46.166] X-CM-SenderInfo: x2klx3xlid0iqsrtqiywtou0bp/xtbBZx9LU2V4I6SmaAABs1 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk David Rowley writes: > On Fri, 30 Aug 2024 at 13:04, Andy Fan wrote: >> >> David Rowley writes: >> > If there's anywhere we call output functions >> > where the resulting value isn't directly appended to a StringInfo, >> > then we could just use a temporary StringInfo to obtain the cstring >> > and its length. >> >> I think this is true, but it requests some caller's code change. > > Yeah, calling code would need to be changed to take advantage of the > new API, however, the differences in which types support which API > could be hidden inside OutputFunctionCall(). That function could just > fake up a StringInfo for any types that only support the old cstring > API. That means we don't need to add handling for both cases > everywhere we need to call the output function. We can do this, then the printtup case (stands for some performance crital path) still need to change discard OutputFunctionCall() since it uses the fake StringInfo then a memcpy is needed again IIUC. Besides above, my major concerns about your proposal need to change [all the type's outfunction at once] which is too aggresive for me. In the fresh setup without any extension is created, "SELECT count(*) FROM pg_type" returns 627 already, So other piece of my previous reply is more important to me. It is great that both of us feeling the current stategy is not good for performance:) -- Best Regards Andy Fan