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 1qR4vL-000Tlr-Vl for pgsql-hackers@arkaria.postgresql.org; Wed, 02 Aug 2023 06:01:32 +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 1qR4vK-002qAq-EV for pgsql-hackers@arkaria.postgresql.org; Wed, 02 Aug 2023 06:01:30 +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 1qR4vK-002qAi-3z for pgsql-hackers@lists.postgresql.org; Wed, 02 Aug 2023 06:01:30 +0000 Received: from mail-vs1-xe36.google.com ([2607:f8b0:4864:20::e36]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qR4vI-0005XX-5p for pgsql-hackers@postgresql.org; Wed, 02 Aug 2023 06:01:29 +0000 Received: by mail-vs1-xe36.google.com with SMTP id ada2fe7eead31-444f9c0b2a4so2195925137.1 for ; Tue, 01 Aug 2023 23:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690956086; x=1691560886; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=WQ9A5aMlUehWFHvBNHvJMqz4TlBoa9TwZOiZOjC0a58=; b=RgBM7aKE5tcXdBX2oaSdEr8l6ZRcBM7kOlulZ3qrleNeMJRpCi0szP+vkInAgSagLu wg6/YXcGZyjULCqTkHT8Ik3QYRRUAODHReLe0dN7nAec25moouNvWiuFApjDOzqEOFuQ CiskYZUVUR5N3yF2l/3X33ouAOvZXjeQdlWI9tmsd/Qii0KkXQzsVw12a6EYqoJu7XBr ShM8z9R70NseP7XsO+9dPGAyzu+4lGYoPt8hQ2GTTGla2iQGTkbFyPwyRCXtHTck53lk iIdJUNBKhD9H6LwLRYsmMmSeF5ujh4mG0I9H7dmdq/mdM0JzR69X1VP+ZIzoiggUK8vV /7Yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690956086; x=1691560886; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=WQ9A5aMlUehWFHvBNHvJMqz4TlBoa9TwZOiZOjC0a58=; b=lP+0l8UT90wzgOrD4E5XBlZRUec/939IbF3GZx3fm78YaXJiE9gJ4gtFzxFNpiIUXI 9dj/IbAj0M7bfOTUQxChiewRnvhPJOd8NpQc+Qkr1yWzM7QAAKJzaZcnUURklW3rEbxx 0XYTcRvePf956hzLeu0THquelEvCemwChd8UfRISSrLPx09flKxdfWCWGRvLVk+BuVIF APayPUTSKu7vSISAuTns0Jwjzf413TnL67JCUDkv0Hohy+GLH23xbwJcnsEqzAfH7aGg zFhF8wMyajgaHwe4Cw5ogrWpQMGQQR6N0Ujv5lBkM4fEVZGAIjjkTfKSnXBfIcsUT/JF PjnA== X-Gm-Message-State: ABy/qLZUJ99wkrHQa3w1QwbC7RlDlQFykesAuIr9Ox/wxq5PYCkZpWAb k9iXfvrMhx5w0+yhUD4to5XYFzYri0P16iUzuTU= X-Google-Smtp-Source: APBJJlHBlys2r8D7V2zIUK6an4/7yLLSD3CoI1PUyjnrNCJBd9rYckr1CKcBdkA1hvjoAA08aEXqTNS3WaurEeKXOYU= X-Received: by 2002:a05:6102:40a:b0:436:57fc:ffa3 with SMTP id d10-20020a056102040a00b0043657fcffa3mr3681279vsq.23.1690956086238; Tue, 01 Aug 2023 23:01:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: jian he Date: Wed, 2 Aug 2023 14:01:15 +0800 Message-ID: Subject: Re: Extract numeric filed in JSONB more effectively To: Andy Fan Cc: pgsql-hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Aug 1, 2023 at 12:39=E2=80=AFPM Andy Fan = wrote: > > Hi: > > Currently if we want to extract a numeric field in jsonb, we need to use > the following expression: cast (a->>'a' as numeric). It will turn a nume= ric > to text first and then turn the text to numeric again. See > jsonb_object_field_text and JsonbValueAsText. However the binary format > of numeric in JSONB is compatible with the numeric in SQL, so I think we > can have an operator to extract the numeric directly. If the value of a g= iven > field is not a numeric data type, an error will be raised, this can be > documented. > > In this patch, I added a new operator for this purpose, here is the > performance gain because of this. > > create table tb (a jsonb); > insert into tb select '{"a": 1}'::jsonb from generate_series(1, 100000)i; > > current method: > select count(*) from tb where cast (a->>'a' as numeric) =3D 2; > 167ms. > > new method: > select count(*) from tb where a@->'a' =3D 2; > 65ms. > > Is this the right way to go? Testcase, document and catalog version are > updated. > > > -- > Best Regards > Andy Fan return PointerGetDatum(v->val.numeric); should be something like PG_RETURN_NUMERIC(v->val.numeric); ?