Re: Reproducible coliisions in jsonb_hash

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: Reproducible coliisions in jsonb_hash
Дата
Msg-id 20220515160326.GB9030@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: Reproducible coliisions in jsonb_hash  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: gitmaster access
Следующее
От: Matthias van de Meent
Дата:
Сообщение: [RFC] Improving multi-column filter cardinality estimation using MCVs and HyperLogLog