On 05/09/2014 11:44 PM, Tom Lane wrote:
Greg Stark st...@mit.edu writes:
Well the question seems to me to be that if we're always doing recheck
then what advantage is there to not hashing everything?
Right now, there's not much. But it seems likely to me that there will be
more JSON
On 05/10/2014 04:42 PM, Heikki Linnakangas wrote:
The main difference between the two opclasses from a user's standpoint
is not whether they hash or not. The big difference is that one
indexes complete paths from the root, and the other indexes just the
leaf level. For example, if you have
+1
but bit confused with json instead of jsonb
On Sun, May 11, 2014 at 1:00 AM, Andrew Dunstan and...@dunslane.net wrote:
On 05/10/2014 04:42 PM, Heikki Linnakangas wrote:
The main difference between the two opclasses from a user's standpoint is
not whether they hash or not. The big
On Sat, May 10, 2014 at 1:42 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
For example, if you have an object like '{foo: {bar: 123 } }', one will
index foo, foo-bar, and foo-bar-123 while the other will index
foo, bar and 123.
That isn't quite right, if we're talking about the user's
Andrew Dunstan and...@dunslane.net writes:
On 05/10/2014 04:42 PM, Heikki Linnakangas wrote:
Whether the opclasses use hashing to shorten the key is an orthogonal
property, and IMHO not as important. To reflect that, I suggest that
we name the opclasses:
json_path_ops
json_value_ops
On Sat, May 10, 2014 at 2:52 PM, Peter Geoghegan p...@heroku.com wrote:
I've added a wildcard to the rhs jsonb here, which of course won't
work, the proximate cause being that that simply isn't valid jsonb.
It's also something inherently impossible to support with the current
jsonb_hash_op's
Peter Geoghegan p...@heroku.com writes:
Now, I'm not all that worried about this, because this is surely an
odd-ball use case, particularly for jsonb_hash_ops where no keys are
separately indexed (separately from *primitive* elements/values).
However, it is worth noting in the documentation in
On Sat, May 10, 2014 at 5:54 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not sure whether we have consensus to rename jsonb_hash_ops to
jsonb_path_ops, but since time is so short I went ahead and made a draft
patch to do so (attached). Probably the most interesting part of this is
the new text
Peter Geoghegan p...@heroku.com writes:
On Sat, May 10, 2014 at 5:54 PM, Tom Lane t...@sss.pgh.pa.us wrote:
+ especially if
+ there are a very large number of rows containing any single one of the
+ three keys
I suggest that you phrase this as three index items.
Good idea ---
Gavin Flower gavinflo...@archidevsys.co.nz writes:
On 09/05/14 15:34, Bruce Momjian wrote:
Looks good. I was thinking the jsonb_ops name could remain unchanged
and the jsonb_hash_ops could be called jsonb_combo_ops as it combines
the key and value into a single index entry.
If you have
On Fri, May 9, 2014 at 07:04:17AM -0400, Tom Lane wrote:
Gavin Flower gavinflo...@archidevsys.co.nz writes:
On 09/05/14 15:34, Bruce Momjian wrote:
Looks good. I was thinking the jsonb_ops name could remain unchanged
and the jsonb_hash_ops could be called jsonb_combo_ops as it combines
On Fri, May 9, 2014 at 09:53:36AM -0400, Bruce Momjian wrote:
On Fri, May 9, 2014 at 07:04:17AM -0400, Tom Lane wrote:
Gavin Flower gavinflo...@archidevsys.co.nz writes:
On 09/05/14 15:34, Bruce Momjian wrote:
Looks good. I was thinking the jsonb_ops name could remain unchanged
and
On Fri, May 9, 2014 at 2:53 PM, Bruce Momjian br...@momjian.us 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
On 2014-05-09 10:26:48 -0400, Bruce Momjian wrote:
On Fri, May 9, 2014 at 09:53:36AM -0400, Bruce Momjian wrote:
On Fri, May 9, 2014 at 07:04:17AM -0400, Tom Lane wrote:
Gavin Flower gavinflo...@archidevsys.co.nz writes:
On 09/05/14 15:34, Bruce Momjian wrote:
Looks good. I was
Greg Stark st...@mit.edu writes:
Well the question seems to me to be that if we're always doing recheck
then what advantage is there to not hashing everything?
Right now, there's not much. But it seems likely to me that there will be
more JSON operators in future, and some of them might be
On Tue, May 6, 2014 at 06:20:53PM -0400, Tom Lane wrote:
David E. Wheeler da...@justatheory.com writes:
On May 6, 2014, at 2:20 PM, Bruce Momjian br...@momjian.us wrote:
Well, then, we only have a few days to come up with a name.
What are the options?
We have no proposals as yet.
Bruce Momjian br...@momjian.us writes:
On Tue, May 6, 2014 at 06:20:53PM -0400, Tom Lane wrote:
I wonder why there's not an option to store keys and values separately,
but as hashes not as the original strings, so that indexability of
everything could be guaranteed. Or a variant of that
On Thu, May 8, 2014 at 10:16:54AM -0400, Tom Lane wrote:
Can we hash just the values, not the keys, in jsonb_ops, and hash the
combo in jsonb_hash_ops. That would give us key-only lookups without a
recheck.
No, because there's nothing in JSON limiting the length of keys, any more
than
On 2014-05-08 10:34:04 -0400, Bruce Momjian wrote:
On Thu, May 8, 2014 at 10:16:54AM -0400, Tom Lane wrote:
Can we hash just the values, not the keys, in jsonb_ops, and hash the
combo in jsonb_hash_ops. That would give us key-only lookups without a
recheck.
No, because there's
On Thu, May 8, 2014 at 04:37:05PM +0200, Andres Freund wrote:
On 2014-05-08 10:34:04 -0400, Bruce Momjian wrote:
On Thu, May 8, 2014 at 10:16:54AM -0400, Tom Lane wrote:
Can we hash just the values, not the keys, in jsonb_ops, and hash the
combo in jsonb_hash_ops. That would give us
I wrote:
I think the idea of hashing only keys/values that are too long is a
reasonable compromise. I've not finished coding it (because I keep
getting distracted by other problems in the code :-() but it does not
look to be very difficult. I'm envisioning the cutoff as being something
like
On Thu, May 8, 2014 at 06:39:11PM -0400, Tom Lane wrote:
I wrote:
I think the idea of hashing only keys/values that are too long is a
reasonable compromise. I've not finished coding it (because I keep
getting distracted by other problems in the code :-() but it does not
look to be very
On 09/05/14 15:34, Bruce Momjian wrote:
On Thu, May 8, 2014 at 06:39:11PM -0400, Tom Lane wrote:
I wrote:
I think the idea of hashing only keys/values that are too long is a
reasonable compromise. I've not finished coding it (because I keep
getting distracted by other problems in the code
On Thu, May 8, 2014 at 3:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Barring objections I'll commit this tomorrow
Looks good to me.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On May 6, 2014, at 2:20 PM, Bruce Momjian br...@momjian.us wrote:
Stuck on the naming question. I'd be willing to do the patch legwork
if we had a consensus (or even a proposal) for what to rename the
current jsonb_ops to.
Well, then, we only have a few days to come up with a name.
What
David E. Wheeler da...@justatheory.com writes:
On May 6, 2014, at 2:20 PM, Bruce Momjian br...@momjian.us wrote:
Well, then, we only have a few days to come up with a name.
What are the options?
We have no proposals as yet.
I've been looking at the source code to try to understand the
On Tue, May 6, 2014 at 3:20 PM, Tom Lane t...@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
Peter Geoghegan p...@heroku.com writes:
On Tue, May 6, 2014 at 3:20 PM, Tom Lane t...@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
On May 6, 2014, at 3:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
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
On Tue, May 6, 2014 at 3:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
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
30 matches
Mail list logo
