From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@heroku.com>
cc: pgsql-hackers@postgresql.org
Subject: default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass
 documentation)
In-reply-to: 
 <CAM3SWZRAxisGCdODhbgeiNL6tayqL18XMzun4W3xesASmKfwDA@mail.gmail.com>
References: <27299.1396989666@sss.pgh.pa.us>
 <CAM3SWZQGZyqSBzaFZ4gmtnQZpcXLE=ceUL_O29gtMgnP=AvC+g@mail.gmail.com>
 <28589.1396992841@sss.pgh.pa.us>
 <CAM3SWZRAxisGCdODhbgeiNL6tayqL18XMzun4W3xesASmKfwDA@mail.gmail.com>
Comments: In-reply-to Peter Geoghegan <pg@heroku.com>
 message dated "Tue, 08 Apr 2014 14:39:29 -0700"
Date: Tue, 08 Apr 2014 17:46:22 -0400
Message-ID: <29030.1396993582@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Peter Geoghegan <pg@heroku.com> writes:
> On Tue, Apr 8, 2014 at 2:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> (BTW, wasn't there some discussion of changing our minds about which
>> one is the default?  We already have one bug report complaining about
>> jsonb_ops' size restriction, so that seems to be evidence in favor
>> of changing ...)

> Yes, there was. I very nearly came down on the side of making
> jsonb_hash_ops the default, but given that it doesn't make all
> operators indexable, I ultimately decided against supporting that
> course of action. I thought that that would be an odd limitation for
> the default GIN opclass to have. It was a very close call in my mind,
> and if you favor changing the default now, in light of the few
> complaints we've heard, I think that's a reasonable decision. That
> said, as I noted in the main -bugs thread, the case presented is
> fairly atypical.

Well, let me see if I understand the situation correctly:

* jsonb_ops supports more operators

* jsonb_hash_ops produces smaller, better-performing indexes

* jsonb_ops falls over on inputs with wide field values, but
jsonb_hash_ops does not

If that's an accurate summary then I would say that we've got
the default backwards.  I would much rather tell people "you
can have more operators supported, but here are the tradeoffs"
than have a default that fails under evidently-not-so-improbable
cases.

			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