From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@heroku.com>
cc: "David E. Wheeler" <david@justatheory.com>,
 Bruce Momjian <bruce@momjian.us>, Greg Stark <stark@mit.edu>,
 Robert Haas <robertmhaas@gmail.com>,
 Heikki Linnakangas <hlinnakangas@vmware.com>,
 Andrew Dunstan <andrew@dunslane.net>,
 "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: 
 <CAM3SWZS4Tn-xZOBqM_ds-nhB2wLSpKG86rcJnMSexqDJqWgzNg@mail.gmail.com>
References: 
 <CAM3SWZQzOxmryVe_bdu9WhqbJTBoiqM7knvKm0oRYxvfsFnz7Q@mail.gmail.com>
 <534475B7.6020908@dunslane.net> <5344EAA4.1050605@vmware.com>
 <CA+TgmoZucoe-w5P_16A-gdfRBFCCu7PD17YO-KqrYPBhb5TxAA@mail.gmail.com>
 <30137.1397057056@sss.pgh.pa.us>
 <CAM-w4HNawF2sPDSUrZsng7zgGnste-Vy1+42AufyVq9UkVeCZw@mail.gmail.com>
 <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>
 <CAM3SWZS4Tn-xZOBqM_ds-nhB2wLSpKG86rcJnMSexqDJqWgzNg@mail.gmail.com>
Comments: In-reply-to Peter Geoghegan <pg@heroku.com>
 message dated "Tue, 06 May 2014 15:29:40 -0700"
Date: Tue, 06 May 2014 18:39:37 -0400
Message-ID: <29011.1399415977@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Peter Geoghegan <pg@heroku.com> writes:
> On Tue, May 6, 2014 at 3:20 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.

> I would expect the selectivity of keys on their own to be very low
> with idiomatic usage of jsonb. Typically, every row in a table will
> have almost the same keys. The current default opclass makes more
> sense for when that isn't the case.

Meh.  I would not think that that represents effective use of JSON:
if the rows are all the same, why aren't you exposing that structure
as regular SQL columns?  IMHO, the value of JSON fields within a SQL
table is to deal with data that is not so well structured.

In any case, it was certainly the complaint that insertions might
fail altogether that made me (and I assume others) want to not have
jsonb_ops as the default opclass.  Is there a good reason not to
fix that limitation while we still can?

			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