Received: from malur.postgresql.org ([217.196.149.56])
 by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from
 <pgsql-hackers-owner+M249940=pgsql-hackers-arkari@postgresql.org>)
 id 1Wirf6-00017v-0K
 for pgsql-hackers@arkaria.postgresql.org; Fri, 09 May 2014 20:44:56 +0000
Received: from localhost ([127.0.0.1] helo=postgresql.org)
 by malur.postgresql.org with smtp (Exim 4.80) (envelope-from
 <pgsql-hackers-owner+M249940=pgsql-hackers-arkari@postgresql.org>)
 id 1Wirf5-0000c5-7E
 for pgsql-hackers@arkaria.postgresql.org; Fri, 09 May 2014 20:44:55 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
 by malur.postgresql.org with esmtp (Exim 4.80)
 (envelope-from <tgl@sss.pgh.pa.us>) id 1Wirf1-0000WQ-In
 for pgsql-hackers@postgresql.org; Fri, 09 May 2014 20:44:51 +0000
Received: from sss.pgh.pa.us ([66.207.139.130])
 by magus.postgresql.org with esmtp (Exim 4.80)
 (envelope-from <tgl@sss.pgh.pa.us>) id 1Wirey-0006at-NY
 for pgsql-hackers@postgresql.org; Fri, 09 May 2014 20:44:51 +0000
Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1])
 by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id s49KiWMI028962;
 Fri, 9 May 2014 16:44:32 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Greg Stark <stark@mit.edu>
cc: Bruce Momjian <bruce@momjian.us>,
 Gavin Flower <GavinFlower@archidevsys.co.nz>,
 "David E. Wheeler" <david@justatheory.com>,
 Robert Haas <robertmhaas@gmail.com>,
 Heikki Linnakangas <hlinnakangas@vmware.com>,
 Andrew Dunstan <andrew@dunslane.net>, Peter Geoghegan <pg@heroku.com>,
 "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST
 opclass documentation)
In-reply-to: 
 <CAM-w4HOQ+ynm70Cgr4BwMqMc0jfL_8EZAwG2UD6r=EehjH3OOw@mail.gmail.com>
References: <16769.1399407530@sss.pgh.pa.us>
 <20140506212020.GK30817@momjian.us>
 <57E8AA44-F816-45F2-BB61-5A854FFB0A97@justatheory.com>
 <28554.1399414853@sss.pgh.pa.us> <20140508134701.GO30817@momjian.us>
 <5819.1399558614@sss.pgh.pa.us> <1888.1399588751@sss.pgh.pa.us>
 <20140509033405.GA23254@momjian.us> <536C550F.50108@archidevsys.co.nz>
 <18360.1399633457@sss.pgh.pa.us> <20140509135336.GC23254@momjian.us>
 <CAM-w4HOQ+ynm70Cgr4BwMqMc0jfL_8EZAwG2UD6r=EehjH3OOw@mail.gmail.com>
Comments: In-reply-to Greg Stark <stark@mit.edu>
 message dated "Fri, 09 May 2014 15:26:33 +0100"
Date: Fri, 09 May 2014 16:44:32 -0400
Message-ID: <28961.1399668272@sss.pgh.pa.us>
X-Pg-Spam-Score: -2.6 (--)
List-Archive: <http://archives.postgresql.org/pgsql-hackers>
List-Help: <mailto:majordomo@postgresql.org?body=help>
List-ID: <pgsql-hackers.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@postgresql.org>
List-Post: <mailto:pgsql-hackers@postgresql.org>
List-Subscribe: <mailto:majordomo@postgresql.org?body=sub%20pgsql-hackers>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
X-Mailing-List: pgsql-hackers
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Greg Stark <stark@mit.edu> writes:
> Well the question seems to me to be that if we're always doing recheck
> then what advantage is there to not hashing everything?

Right now, there's not much.  But it seems likely to me that there will be
more JSON operators in future, and some of them might be able to make use
of the additional specificity of unhashed entries.  For example, it's only
a very arbitrary definitional choice for the exists operator (ie, not
looking into sub-objects) that makes jsonb_ops lossy for it.  We might
eventually build a recursive-exists-check operator for which the index
could be lossless, at least up to the string length where we start to
hash.

			regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers