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 1tCpZl-00DTN5-4x for pgsql-hackers@arkaria.postgresql.org; Mon, 18 Nov 2024 00:25:08 +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 1tCpZh-00298W-SA for pgsql-hackers@arkaria.postgresql.org; Mon, 18 Nov 2024 00:25:06 +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 1tCpZh-00298J-4T for pgsql-hackers@lists.postgresql.org; Mon, 18 Nov 2024 00:25:06 +0000 Received: from m16.mail.163.com ([117.135.210.5]) by magus.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tCpZV-002UP1-PC for pgsql-hackers@lists.postgresql.org; Mon, 18 Nov 2024 00:25:03 +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=k03E6IACC4d2nYzIjuDFgQDn7CZmnR4B9cy0LaNTo3s=; b=gb2qhUovW8rULhlBn1V1J5JCnlEdurhHfpeJuWk2IK73vWFaF/nLlpIJmQy30C jAXQLwfUX5Zgmd1/x3wAEl7JiF+3t2SohLfv41dTq+ERT3Zg3ffXuf1bqC6/+Y9u ygRAUjiHE5SJHMp39f3FSoeiT4vNkneYVyZ8eWfCxs5d0= Received: from lovely-coding (unknown [101.227.46.166]) by gzsmtp4 (Coremail) with SMTP id PygvCgDn72kYiTpntBOUDw--.59288S3; Mon, 18 Nov 2024 08:23:53 +0800 (CST) From: Andy Fan To: Dmitry Dolgov <9erthalion6@gmail.com> Cc: David Rowley , Peter Eisentraut , Amit Langote , Alvaro Herrera , jian he , Chapman Flack , pgsql-hackers@lists.postgresql.org Subject: Re: Extract numeric filed in JSONB more effectively In-Reply-To: (Dmitry Dolgov's message of "Fri, 15 Nov 2024 17:30:09 +0100") References: <87h6jpob9x.fsf@163.com> <87r0hmvuvr.fsf@163.com> <8102ff5b-b156-409e-a48f-e53e63a39b36@eisentraut.org> <8734t6c5rh.fsf@163.com> <87o7bn7z56.fsf@163.com> <875xx197bp.fsf@163.com> <87ttk0lgcx.fsf@163.com> <8734m5fua1.fsf@163.com> Date: Mon, 18 Nov 2024 08:23:52 +0800 Message-ID: <87a5dx4cfb.fsf@163.com> MIME-Version: 1.0 Content-Type: text/plain X-CM-TRANSID:PygvCgDn72kYiTpntBOUDw--.59288S3 X-Coremail-Antispam: 1Uf129KBjvJXoW7tw1xXrWDAryfuFWrCF4xXrb_yoW8uFyfp3 y5CF12krWkGrW7CrnrXan3Grn5KrWvyrWUJrn0qw1jkw4Yq3Z2gF4kKr1YkayDtwnxG3sY vayDuFn8Zan09FJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07U33kNUUUUU= X-Originating-IP: [101.227.46.166] X-CM-SenderInfo: x2klx3xlid0iqsrtqiywtou0bp/xtbBZwGaU2c6YGqNjgADs4 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi Dmitry, >> On Thu, Sep 12, 2024 at 03:03:18AM GMT, Andy Fan wrote: >> >> > I imagined you'd the patch should create a SupportRequestSimplify >> > support function for jsonb_numeric() that checks if the input >> > expression is an OpExpr with funcid of jsonb_object_field(). All you >> > do then is ditch the cast and change the OpExpr to call a new function >> > named jsonb_object_field_numeric() which returns the val.numeric >> > directly. Likely the same support function could handle jsonb casts >> > to other types too, in which case you'd just call some other function, >> > e.g jsonb_object_field_timestamp() or jsonb_object_field_boolean(). >> >> Basically yes. The reason complexity comes when we many operators we >> want to optimize AND my patch I want to reduce the number of function >> created. >> >> The optimized functions and operators includes: >> 1. jsonb_object_field / -> >> 2. jsonb_array_element / -> >> 3. jsonb_extract_path / #> >> 4. jsonb_path_query >> 5. jsonb_path_query_first >> >> >> > ..., in which case you'd just call some other function, >> > e.g jsonb_object_field_timestamp() or jsonb_object_field_boolean(). >> >> This works, but We need to create 2 functions for each operator. In the >> patched case, we have 5 operators, so we need to create 10 functions. >> >> op[1,2,3,4,5]_bool >> op[1,2,3,4,5]_numeric. >> >> Within the start / finish function, we need to create *7* functions. > > Any particular reason you want to keep number of functions minimal? Is > it just to make the patch smaller? I might be missing something without > looking at the implementation in details, but the difference between 10 > and 7 functions doesn't seem to be significant. Another reason is for reducing code duplication, writting too many similar function looks not good to me. Chapman expressed this idea first at [1]. Search "it would make me happy to further reduce some of the code" in the message. Acutally this doesn't make the patch complexer too much. [1] https://www.postgresql.org/message-id/5138c6b5fd239e7ce4e1a4e63826ac27%40anastigmatix.net -- Best Regards Andy Fan