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 1qhcFE-003fAY-Go for pgsql-hackers@arkaria.postgresql.org; Sat, 16 Sep 2023 20:50:25 +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 1qhcFC-000zGY-Jh for pgsql-hackers@arkaria.postgresql.org; Sat, 16 Sep 2023 20:50:22 +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 1qhcFC-000zGA-6d for pgsql-hackers@lists.postgresql.org; Sat, 16 Sep 2023 20:50:22 +0000 Received: from mout-u-107.mailbox.org ([80.241.59.207]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qhcF7-005WFc-LV for pgsql-hackers@lists.postgresql.org; Sat, 16 Sep 2023 20:50:21 +0000 Received: from smtp2.mailbox.org (smtp2.mailbox.org [10.196.197.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-u-107.mailbox.org (Postfix) with ESMTPS id 4Rp3916q5lz9smy; Sat, 16 Sep 2023 22:50:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ewie.name; s=MBO0001; t=1694897414; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=tdgQ0lGmbGHTmClUsijOSNNV927OS+ADhTcOxG7x8yk=; b=fn5XSR1zSAzIErF2D223oqHPLyiuhqeu6c46RxziRDTu264I3VoEqZ36MTsFL7g0ipYzt2 ZWjTK/rJKumWnGKm7Dm73Oy2TPt2qGVadjiifTOmn4BK2hMoEHaz6+H4Q4CsLWHKnxY8Vq RxAHe+u5Eai7FOyefraFwxBahmZ37e1zxP9D4ZB7th84WFH3Zj86iRS1gZQMT0FvCwGrSV JiRwLxYLA3tMVc5UEq8AcEcqFHFlXE9HyiEqoYxfWOUa8V+igIRsiPyqG9WZB/23ETktfF A567lma8rLAScIjPy8QpzNAXp7jOzGcvMiozfcSDKtGNAiU/NHTleCYc/MGPlw== Date: Sat, 16 Sep 2023 22:50:13 +0200 (CEST) From: Erik Wienhold To: "David E. Wheeler" , Erik Rijkers Cc: pgsql-hackers@lists.postgresql.org Message-ID: <164182692.82468.1694897413058@office.mailbox.org> In-Reply-To: References: <15DD78A5-B5C4-4332-ACFE-55723259C07F@justatheory.com> <133696180.303713.1694566807910@office.mailbox.org> <729CC2EA-9194-459C-B2A6-BC660F62E6A9@justatheory.com> <973d6495-cf28-4d06-7d46-758bd2615e34@xs4all.nl> Subject: Re: JSON Path and GIN Questions MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 16/09/2023 22:19 CEST David E. Wheeler wrote: > On Sep 15, 2023, at 23:59, Erik Rijkers wrote: > > > 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. > > Is that a limitation of GIN indexes in general? Or could there be opclass > improvements in the future that would enable such comparisons? This detail is mentioned in docs [1]: "For these operators, a GIN index extracts clauses of the form **accessors_chain = constant** out of the jsonpath pattern, and does the index search based on the keys and values mentioned in these clauses." I don't know if this is a general limitation of GIN indexes or just how these operators are implemented right now. [1] https://www.postgresql.org/docs/current/datatype-json.html#JSON-INDEXING -- Erik