Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Willh-0002TH-IQ for pgsql-hackers@arkaria.postgresql.org; Fri, 09 May 2014 14:27:21 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Willg-0001v8-VT for pgsql-hackers@arkaria.postgresql.org; Fri, 09 May 2014 14:27:21 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Wille-0001tH-Ty for pgsql-hackers@postgresql.org; Fri, 09 May 2014 14:27:18 +0000 Received: from mail-ig0-x232.google.com ([2607:f8b0:4001:c05::232]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Willa-0008S3-Ru for pgsql-hackers@postgresql.org; Fri, 09 May 2014 14:27:18 +0000 Received: by mail-ig0-f178.google.com with SMTP id hl10so1180978igb.17 for ; Fri, 09 May 2014 07:27:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=9UHNlQoWo1WmkOBzLNG7M7+VkL2/xA1rq8iimCSk0xs=; b=votVrwAzkHao0JFgtIv4FsjTOOFXMQSUDYB3oZ47GrDqjCVXflThN99JqgxsNGZ+if 3LwFaN1aHZyzs2CIeTj9RWjYEclcZDQOVG5TYRAG1piMO/VbKMPjN4i//vj77BMYQqB6 4jJKOjW2DZ11N5CwgkCe0N2dlGZnuhuN5aYawYiO3Txv6fDkIou54D/vAEnhnY0EyH+K bzr+vydSZ1Pw1F9YSJ9yLT8c5SpDWK54g5FAGbLWsdiHIj4W99o5cGZr5sy5k3rwjcev jLpz7ktDJ7k0scC1VWeYQ6l9zEVbeEghLSTycn0s7ST8hsPn2ZUxc59N7jmcYxflytSf 4Tfw== X-Received: by 10.50.118.69 with SMTP id kk5mr9797799igb.10.1399645633102; Fri, 09 May 2014 07:27:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.18.200 with HTTP; Fri, 9 May 2014 07:26:33 -0700 (PDT) In-Reply-To: <20140509135336.GC23254@momjian.us> 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> From: Greg Stark Date: Fri, 9 May 2014 15:26:33 +0100 X-Google-Sender-Auth: yzbjfxoCNUzDEwHgB42kGtpil9k Message-ID: Subject: Re: default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation) To: Bruce Momjian Cc: Tom Lane , Gavin Flower , "David E. Wheeler" , Robert Haas , Heikki Linnakangas , Andrew Dunstan , Peter Geoghegan , "pgsql-hackers@postgresql.org" Content-Type: text/plain; charset=UTF-8 X-Pg-Spam-Score: -1.9 (-) 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 On Fri, May 9, 2014 at 2:53 PM, Bruce Momjian wrote: > Well, if we are optionally hashing json_ops for long strings, what does > jsonb_hash_ops do uniquely with hashing? Does it always hash, while > json_ops optionally hashes? Is that the distinguishing characteristic? > It seemed the _content_ of the indexed value was more important, rather > than the storage method. > > Should jsonb_hash_ops do only optional hashing too for long strings? Well the question seems to me to be that if we're always doing recheck then what advantage is there to not hashing everything? -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers