| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de>, Greg Burd <greg(at)burd(dot)me>, pgsql-hackers(at)postgresql(dot)org |
| Cc: | michael(at)paquier(dot)xyz, thomas(dot)munro(at)gmail(dot)com, exclusion(at)gmail(dot)com, amit(dot)kapila16(at)gmail(dot)com, hlinnaka(at)iki(dot)fi |
| Subject: | Re: WAL record CRC calculated incorrectly because of underlying buffer modification |
| Date: | 2026-10-29 20:49:39 |
| Message-ID: | 2415c781fae2f9139a2397726c23b8cd1d23f8c0.camel@j-davis.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, 2026-10-26 at 11:15 -0400, Andres Freund wrote:
> The advantage hash does have, i.e. large key handling, would have
> better been addressed by adding support to transparently btree
> indexing a hash of the key + recheck.
In theory we could generalize this. We can take any predicate x=a,
create a new implied predicate f(x)=f(a), and then use a functional
index on f(x). (Assuming f() satisfies the right properties and
equality means the very same value.)
The planner wouldn't need any extra logic to recheck, because the x=a
predicate is still there. If there's no index on (x) but there's an
index on (f(x)), then we can see if f is a member of a hash opclass, or
if it's IMMUTABLE & LEAKPROOF, and I think that's enough.
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Burd | 2026-10-29 20:53:33 | Re: Tepid: selective index updates for heap relations |
| Previous Message | Greg Burd | 2026-10-29 20:46:03 | Re: Expanding HOT updates for expression and partial indexes |