From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Donghang Lin <donghanglin(at)gmail(dot)com> |
Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: interval_ops shall stop using btequalimage (deduplication) |
Date: | 2023-10-23 13:07:10 |
Message-ID: | 20231023130710.00.nmisch@google.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2023-10-23 14:03:54 | Re: Fix output of zero privileges in psql |
Previous Message | shveta malik | 2023-10-23 12:56:22 | Re: Synchronizing slots from primary to standby |