On Wed, Apr 9, 2014 at 8:24 AM, Tom Lane wrote:
>> Maybe we should make *neither* of these the default opclass, and give
>> *neither* the name json_ops.
>
> There's definitely something to be said for that. Default opclasses are
> sensible when there's basically only one behavior that's interesti
Alvaro Herrera writes:
> Tom Lane wrote:
>> One other point here is that non-default opclasses can't be used in
>> UNIQUE/PRIMARY KEY/EXCLUDE constraints, because there's no place to
>> specify an opclass name in those syntaxes. UNIQUE/PRIMARY KEY don't
>> matter here since these aren't btree opc
Tom Lane wrote:
> > On Wed, Apr 9, 2014 at 2:37 AM, Heikki Linnakangas
> > wrote:
> >> Both of the operator classes are actually much less flexible than I'd like.
>
> > Maybe we should make *neither* of these the default opclass, and give
> > *neither* the name json_ops.
+1. I was thinking the
Robert Haas writes:
> On Wed, Apr 9, 2014 at 2:37 AM, Heikki Linnakangas
> wrote:
>> Both of the operator classes are actually much less flexible than I'd like.
> Maybe we should make *neither* of these the default opclass, and give
> *neither* the name json_ops.
There's definitely something to
On Wed, Apr 9, 2014 at 2:37 AM, Heikki Linnakangas
wrote:
> Both of the operator classes are actually much less flexible than I'd like.
> Firstly, they index everything. In many cases, that's not what you want, so
> you end up with much larger indexes than necessary. Secondly, jsonb_ops
> indexes
On Wed, Apr 9, 2014 at 12:40 PM, Peter Geoghegan wrote:
> On Wed, Apr 9, 2014 at 1:21 AM, Heikki Linnakangas
> wrote:
> > I didn't say that. On the contrary, I think the shotgun approach
> jsonb_ops
> > and jsonb_hash_ops take is too broad. It should be possible to specify
> what
> > to index in
On Wed, Apr 9, 2014 at 10:37 AM, Heikki Linnakangas wrote:
> The ship has cleatly sailed to add parameterized opclasses to 9.4, but
> let's keep it in mind when we decide on the defaults.
>
> In the absence of parameterizable opclasses, it would be much more
> flexible to have opclasses that inde
On Wed, Apr 9, 2014 at 1:21 AM, Heikki Linnakangas
wrote:
> I didn't say that. On the contrary, I think the shotgun approach jsonb_ops
> and jsonb_hash_ops take is too broad. It should be possible to specify what
> to index in a more detailed fashion.
It is - use an expression index. That's by fa
On 04/09/2014 10:40 AM, Peter Geoghegan wrote:
On Tue, Apr 8, 2014 at 11:37 PM, Heikki Linnakangas
wrote:
As the code stands, you don't have a choice on any of those things. The
decisions have been made by us, PostgreSQL developers. The only choice you
have is between jsonb_ops and jsonb_hash_o
On Tue, Apr 8, 2014 at 11:37 PM, Heikki Linnakangas
wrote:
> As the code stands, you don't have a choice on any of those things. The
> decisions have been made by us, PostgreSQL developers. The only choice you
> have is between jsonb_ops and jsonb_hash_ops, with a strange combination of
> tradeoff
On 04/09/2014 01:18 AM, Andrew Dunstan wrote:
On 04/08/2014 05:57 PM, Peter Geoghegan wrote:
On Tue, Apr 8, 2014 at 2:46 PM, Tom Lane wrote:
Well, let me see if I understand the situation correctly:
* jsonb_ops supports more operators
* jsonb_hash_ops produces smaller, better-performing ind
Andrew Dunstan writes:
> On 04/08/2014 05:57 PM, Peter Geoghegan wrote:
>> ... I didn't propose changing the default due to
>> concerns about the POLA, but I'm happy to be told that those concerns
>> were out of proportion to the practical benefits of a different
>> default.
> I tend to agree wit
On 04/08/2014 05:57 PM, Peter Geoghegan wrote:
On Tue, Apr 8, 2014 at 2:46 PM, Tom Lane wrote:
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 wid
On Tue, Apr 8, 2014 at 2:46 PM, Tom Lane wrote:
> 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 doe
Peter Geoghegan writes:
> On Tue, Apr 8, 2014 at 2:34 PM, Tom Lane 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 ch
On Tue, Apr 8, 2014 at 2:34 PM, Tom Lane 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
Peter Geoghegan writes:
> On Tue, Apr 8, 2014 at 1:41 PM, Tom Lane wrote:
>> Of the two operator classes for type jsonb, jsonb_ops is the
>> default. jsonb_hash_ops supports fewer operators but will work with
>> larger indexed values than jsonb_ops can support.
>>
>> Is that accurate? Do we nee
On Tue, Apr 8, 2014 at 1:41 PM, Tom Lane wrote:
> I just created sections in the SGML manual chapters about GIST, GIN, and
> SP-GIST to hold documentation about the standard opclasses provided for
> them:
I think that that's a good idea. I too was bothered by this omission.
> Of the two oper
I just created sections in the SGML manual chapters about GIST, GIN, and
SP-GIST to hold documentation about the standard opclasses provided for
them:
http://www.postgresql.org/docs/devel/static/gist-builtin-opclasses.html
http://www.postgresql.org/docs/devel/static/gin-builtin-opclasses.html
http
19 matches
Mail list logo
