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 t...@sss.pgh.pa.us wrote:
Well, let me see if I understand the situation correctly:
* jsonb_ops supports more operators
* jsonb_hash_ops produces smaller,
On Tue, Apr 8, 2014 at 11:37 PM, Heikki Linnakangas
hlinnakan...@vmware.com 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
On 04/09/2014 10:40 AM, Peter Geoghegan wrote:
On Tue, Apr 8, 2014 at 11:37 PM, Heikki Linnakangas
hlinnakan...@vmware.com 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
On Wed, Apr 9, 2014 at 1:21 AM, Heikki Linnakangas
hlinnakan...@vmware.com 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
On Wed, Apr 9, 2014 at 10:37 AM, Heikki Linnakangas hlinnakan...@vmware.com
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
On Wed, Apr 9, 2014 at 12:40 PM, Peter Geoghegan p...@heroku.com wrote:
On Wed, Apr 9, 2014 at 1:21 AM, Heikki Linnakangas
hlinnakan...@vmware.com 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
On Wed, Apr 9, 2014 at 2:37 AM, Heikki Linnakangas
hlinnakan...@vmware.com 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,
Robert Haas robertmh...@gmail.com writes:
On Wed, Apr 9, 2014 at 2:37 AM, Heikki Linnakangas
hlinnakan...@vmware.com 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
Tom Lane wrote:
On Wed, Apr 9, 2014 at 2:37 AM, Heikki Linnakangas
hlinnakan...@vmware.com 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
Alvaro Herrera alvhe...@2ndquadrant.com 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
On Wed, Apr 9, 2014 at 8:24 AM, Tom Lane t...@sss.pgh.pa.us 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
On Tue, Apr 8, 2014 at 2:46 PM, Tom Lane t...@sss.pgh.pa.us 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
On 04/08/2014 05:57 PM, Peter Geoghegan wrote:
On Tue, Apr 8, 2014 at 2:46 PM, Tom Lane t...@sss.pgh.pa.us 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
Andrew Dunstan and...@dunslane.net 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
14 matches
Mail list logo
