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 1sjq47-004bKs-70 for pgsql-hackers@arkaria.postgresql.org; Fri, 30 Aug 2024 01:04:39 +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 1sjq42-00B3C2-O2 for pgsql-hackers@arkaria.postgresql.org; Fri, 30 Aug 2024 01:04:35 +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 1sjq41-00B3Bg-Vo for pgsql-hackers@lists.postgresql.org; Fri, 30 Aug 2024 01:04:34 +0000 Received: from m16.mail.163.com ([117.135.210.3]) by makus.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sjq3v-00268r-G8 for pgsql-hackers@postgresql.org; Fri, 30 Aug 2024 01:04:31 +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=6fvYUflTWTNnfuVj7o+qITlaO24LpNvzNDNy21sNMIw=; b=I74Lh0Be/DXi/jKO/gzIhvRExW9kljc25rcgcqopKhEhgeUCZMyVPgR1AfScwc pAi9COrItPizF57RMcNFhRDUWjBGgMkYlPdkOlCdXqztAD6U94VQVLjpZd9MM+LV TUV0uipx8+mMR8e9g9P9fhw8faRELfyL2IyZmpvWx+tTU= Received: from lovely-coding (unknown [101.227.46.166]) by gzga-smtp-mta-g3-0 (Coremail) with SMTP id _____wC3f6KSGtFmG4h3BA--.39265S3; Fri, 30 Aug 2024 09:04:19 +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 12:38:50 +1200") References: <87wmjzfz0h.fsf@163.com> <87bk1aj2go.fsf@163.com> Date: Fri, 30 Aug 2024 09:04:18 +0800 Message-ID: <877cbyizxp.fsf@163.com> MIME-Version: 1.0 Content-Type: text/plain X-CM-TRANSID: _____wC3f6KSGtFmG4h3BA--.39265S3 X-Coremail-Antispam: 1Uf129KBjvJXoW7WFWftF4xZw4xtF43AFyUtrb_yoW8Gr43pa 9akry3Krn5Ar47Awn29F4rZr4ayrs7tFsrZFn8Wryrua4UWF4vgFs5KFWqv3WxuF1SyrWF vFW2vw1DG3WvvaUanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0zRrR6xUUUUU= X-Originating-IP: [101.227.46.166] X-CM-SenderInfo: x2klx3xlid0iqsrtqiywtou0bp/1tbiNhVLU2XAnPusQAAAsV 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 12:10, Andy Fan wrote: >> What would be the extra benefit we redesign all the out functions? > > If I've understood your proposal correctly, it sounds like you want to > invent a new "print" output function for each type to output the Datum > onto a StringInfo, Mostly yes, but not for [each type at once], just for the [common used type], like int2/4/8, float4/8, date/time/timestamp, text/.. and so on. > if that's the case, what would be the point of having both versions? The biggest benefit would be compatibility. In my opinion, print function (not need to be in pg_type at all) is as an optimization and optional, in some performance critical path we can replace the out-function with printfunction, like (printtup). if such performance-critical path find a type without a print-function is defined, just keep the old way. Kind of like supportfunction for proc, this is for data type? Within this way, changes would be much smaller and step-by-step. > 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. -- Best Regards Andy Fan