Re: Reproducible coliisions in jsonb_hash - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Reproducible coliisions in jsonb_hash
Date
Msg-id 20220515160326.GB9030@tamriel.snowman.net
Whole thread Raw
In response to Re: Reproducible coliisions in jsonb_hash  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Greetings,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > Here, that doesn't seem too likely. You could have a column that
> > contains 'tom' and ['tom'] and [['tom']] and [[['tom']]] and so forth
> > and they all get mapped onto the same bucket and you're sad. But
> > probably not.
>
> Yeah, that might be a more useful way to think about it: is this likely
> to cause performance-critical collisions in practice?  I agree that
> that doesn't seem like a very likely situation, even given that you
> might be using json for erratically-structured data.

Particularly for something like jsonb (but maybe other things?) having a
hash function that could be user-defined or at least have some options
seems like it would be quite nice (similar to compression...).  If we
were to go in the direction of changing this, I'd suggest that we try to
make it something where the existing function could still be used while
also allowing a new one to be used.  More flexibility would be even
better, of course (column-specific hash functions comes to mind...).

Agreed with the general conclusion here also, just wanted to share some
thoughts on possible future directions to go in.

Thanks,

Stephen

Attachment

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: gitmaster access
Next
From: Matthias van de Meent
Date:
Subject: [RFC] Improving multi-column filter cardinality estimation using MCVs and HyperLogLog