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 1qhMQi-002Dhh-Lq for pgsql-hackers@arkaria.postgresql.org; Sat, 16 Sep 2023 03:57:13 +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 1qhMQg-005fj2-Hv for pgsql-hackers@arkaria.postgresql.org; Sat, 16 Sep 2023 03:57:10 +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 1qhMQg-005fhh-4n for pgsql-hackers@lists.postgresql.org; Sat, 16 Sep 2023 03:57:10 +0000 Received: from ewsoutbound.kpnmail.nl ([195.121.94.185]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qhMQW-005NQe-Vk for pgsql-hackers@lists.postgresql.org; Sat, 16 Sep 2023 03:57:08 +0000 X-KPN-MessageId: 142c568a-5445-11ee-a194-005056999439 Received: from smtp.kpnmail.nl (unknown [10.31.155.6]) by ewsoutbound.so.kpn.org (Halon) with ESMTPS id 142c568a-5445-11ee-a194-005056999439; Sat, 16 Sep 2023 05:56:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xs4all.nl; s=xs4all01; h=content-type:from:to:subject:mime-version:date:message-id; bh=HFRycl8RN5MGoBOYMIz+51a471zTaACEut6XXRcQHVs=; b=iSqGuHTGWmKwJGfk4YDxLwFFQKk3SRyTG4jXN6W268VTXNCKWB1kne+sd8IywvYjJff/nL28QRD8l oL4EgMatig4fB/irs3U85/yVRWS4UB6pUFDywIf2gBc3Qsn4MLyrUav+Yu5MOQYLJZEq1sxreXD8gs 8PQDhSNT1UxETSRExHwDrkuCmmkUPO3TXFlPDhmtHk9buPp+DtSLb1qA2aLlSmoR73FOeFbP5bwgh0 OH6fsN6eBLDfrNkfgM8nYBOv5iARziKnHoCE3+nhfrA5noBRlyOWUHcW759guPmsKoRtG5i2t2uY4r QEgG2oJzVy8plEU8bARB7r/u53a1m4Q== X-KPN-MID: 33|I0mmUdur8qMTKiQvHtZjAPBRpNm5MoFBkh+e0/g0zurLArRHfjVVCmlBBLbUia8 HjwDvcTNXG+GcT9DFaQLrmmzTHOhSzCjaeYfgKkCMK5I= X-KPN-VerifiedSender: Yes X-CMASSUN: 33|m4AKKmZloGUXH1Zy++NMo+QHpJZShZPzkb8DVxREJ/H4V+Xd2yAMlKXA4Ag+jAO 5UB3MJCqzupqV9CumYdPI8w== X-Originating-IP: 45.83.234.25 Received: from [192.168.178.31] (unknown [45.83.234.25]) by smtp.xs4all.nl (Halon) with ESMTPSA id 12253363-5445-11ee-9dc8-00505699772e; Sat, 16 Sep 2023 05:56:59 +0200 (CEST) Message-ID: <973d6495-cf28-4d06-7d46-758bd2615e34@xs4all.nl> Date: Sat, 16 Sep 2023 05:59:26 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: JSON Path and GIN Questions Content-Language: en-US To: "David E. Wheeler" , Erik Wienhold Cc: pgsql-hackers@lists.postgresql.org References: <15DD78A5-B5C4-4332-ACFE-55723259C07F@justatheory.com> <133696180.303713.1694566807910@office.mailbox.org> <729CC2EA-9194-459C-B2A6-BC660F62E6A9@justatheory.com> From: Erik Rijkers In-Reply-To: <729CC2EA-9194-459C-B2A6-BC660F62E6A9@justatheory.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Op 9/15/23 om 22:27 schreef David E. Wheeler: > On Sep 12, 2023, at 21:00, Erik Wienhold wrote: > >> That's also my understanding. We had a discussion about the docs on @@, @?, and >> jsonb_path_query on -general a while back [1]. Maybe it's useful also. > > Okay, I’ll take a pass at expanding the docs on this. I think a little mini-tutorial on these two operators would be useful. > > Meanwhile, I’d like to re-up this question about the index qualification of non-equality JSON Path operators. > > On Sep 12, 2023, at 20:16, David E. Wheeler wrote: > >> Issue 3: Index Use for Comparison >> --------------------------------- >> >> From the docs (https://www.postgresql.org/docs/current/datatype-json.html#JSON-INDEXING), I had assumed any JSON Path query would be able to use the GIN index. However while the use of the == JSON Path operator is able to take advantage of the GIN index, apparently the >= operator cannot: >> >> david=# explain analyze select id from movies where movie @? '$ ?($.year >= 2023)'; >> QUERY PLAN --------------------------------------------------------------------------------------------------------- >> Seq Scan on movies (cost=0.00..3741.41 rows=366 width=4) (actual time=34.815..36.259 rows=192 loops=1) >> Filter: (movie @? '$?($."year" >= 2023)'::jsonpath) >> Rows Removed by Filter: 36081 >> Planning Time: 1.864 ms >> Execution Time: 36.338 ms >> (5 rows) >> >> Is this expected? Originally I tried with json_path_ops, which I can understand not working, since it stores hashes of paths, which would allow only exact matches. But a plain old GIN index doesn’t appear to work, either. Should it? Is there perhaps some other op class that would allow it to work? Or would I have to create a separate BTREE index on `movie -> 'year'`? > movie @? '$ ?($.year >= 2023)' I believe it is indeed not possible to have such a unequality-search use the GIN index. It is another weakness of JSON that can be unexpected to those not in the fullness of Knowledge of the manual. Yes, this too would be good to explain in the doc where JSON indexes are explained. Erik Rijkers > Thanks, > > David >