Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WiP8I-0006iZ-2I for pgsql-hackers@arkaria.postgresql.org; Thu, 08 May 2014 14:17:10 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1WiP8H-0006lg-H0 for pgsql-hackers@arkaria.postgresql.org; Thu, 08 May 2014 14:17:09 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WiP8G-0006lY-IK for pgsql-hackers@postgresql.org; Thu, 08 May 2014 14:17:08 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WiP8D-0007wK-Hq for pgsql-hackers@postgresql.org; Thu, 08 May 2014 14:17:08 +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 s48EGsov005820; Thu, 8 May 2014 10:16:54 -0400 From: Tom Lane To: Bruce Momjian cc: "David E. Wheeler" , Greg Stark , Robert Haas , Heikki Linnakangas , Andrew Dunstan , Peter Geoghegan , "pgsql-hackers@postgresql.org" Subject: Re: default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation) In-reply-to: <20140508134701.GO30817@momjian.us> References: <30137.1397057056@sss.pgh.pa.us> <20140422223230.GL10046@momjian.us> <16527.1398214220@sss.pgh.pa.us> <20140506201048.GI30817@momjian.us> <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> Comments: In-reply-to Bruce Momjian message dated "Thu, 08 May 2014 09:47:01 -0400" Date: Thu, 08 May 2014 10:16:54 -0400 Message-ID: <5819.1399558614@sss.pgh.pa.us> X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Bruce Momjian writes: > On Tue, May 6, 2014 at 06:20:53PM -0400, Tom Lane wrote: >> I wonder why there's not an option to store keys and values separately, >> but as hashes not as the original strings, so that indexability of >> everything could be guaranteed. Or a variant of that might be to hash >> only strings that are too large to fit in an index entry, and force >> recheck only when searching for a string that needed hashing. >> >> I wonder whether the most effective use of time at this point >> wouldn't be to fix jsonb_ops to do that, rather than arguing about >> what to rename it to. If it didn't have the failure-for-long-strings >> problem I doubt anybody would be unhappy about making it the default. > Can we hash just the values, not the keys, in jsonb_ops, and hash the > combo in jsonb_hash_ops. That would give us key-only lookups without a > recheck. No, because there's nothing in JSON limiting the length of keys, any more than values. I think the idea of hashing only keys/values that are "too long" is a reasonable compromise. I've not finished coding it (because I keep getting distracted by other problems in the code :-() but it does not look to be very difficult. I'm envisioning the cutoff as being something like 128 bytes; in practice that would mean that few if any keys get hashed, I think. 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