Re: interval_ops shall stop using btequalimage (deduplication)
От | Noah Misch |
---|---|
Тема | Re: interval_ops shall stop using btequalimage (deduplication) |
Дата | |
Msg-id | 20231023130710.00.nmisch@google.com обсуждение исходный текст |
Ответ на | Re: interval_ops shall stop using btequalimage (deduplication) (Donghang Lin <donghanglin@gmail.com>) |
Список | pgsql-hackers |
On Mon, Oct 16, 2023 at 11:21:20PM -0700, Donghang Lin wrote: > > I've also caught btree posting lists where one TID refers to a '1d' heap > > tuple, while another TID refers to a '24h' heap tuple. amcheck complains. > Index-only scans can return the '1d' bits where the actual tuple had the > '24h' > bits. > > Have a build without the patch. I can't reproduce amcheck complaints in > release mode > where all these statements succeed. The queries I shared don't create the problematic structure, just an assertion failure. > > * Generic "equalimage" support function. > > * > > * B-Tree operator classes whose equality function could safely be > replaced by > > * datum_image_eq() in all cases can use this as their "equalimage" support > > * function. > It seems to me that as long as a data type has a deterministic sort but not > necessarily be equalimage, > it should be able to support deduplication. e.g for interval type, we add > a byte wise tie breaker > after '24h' and '1day' are compared equally. In the btree, '24h' and '1day' > are still adjacent, > '1day' is always sorted before '24h' in a btree page, can we do dedup for > each value > without problem? Yes. I'm not aware of correctness obstacles arising if one did that.
В списке pgsql-hackers по дате отправления: