On Tue, Mar 11, 2014 at 5:19 AM, Peter Geoghegan <pg@heroku.com> wrote:
On Mon, Mar 10, 2014 at 4:19 AM, Alexander Korotkov <aekorotkov@gmail.com> wrote: > Here it is.
So it looks like what you have here is analogous to the other problems that I fixed with both GiST and GIN. That isn't surprising, and this does fix my test-case. I'm not terribly happy about the lack of explanation for the hashing in that loop, though. Why use COMP_CRC32() at all, for one thing?
Why do this for non-primitive jsonb hashing?
COMP_CRC32(stack->hash_state, PATH_SEPARATOR, 1);
Where PATH_SEPARATOR is:
#define PATH_SEPARATOR ("\0")
Actually, come to think of it, why not just use one hashing function everywhere? i.e., jsonb_hash(PG_FUNCTION_ARGS)? It's already very similar. Pretty much every hash operator support function 1 (i.e. a particular type's hash function) is implemented with hash_any(). Can't we just do the same here? In any case it isn't obvious why the requirements for those two things (the hashing mechanism used by the jsonb_hash_ops GIN opclass, and the hash operator class support function 1 hash function) cannot be the same thing.
It's because CRC32 interface allows incremental calculation while hash_any requires single chunk of memory. I don't think that unfolding everything is good idea. But we could implement incremental interface for hash_any.