On 2026-10-26 Andres Freund wrote: > I think they're almost unused and don't offer enough advantage over btree > (and perform catastrophically bad in many cases). Instead of making them WAL > logged a few years back; we should have just ripped them out.
Fair, whether hash earns its place is a bigger conversation than this bug. I'll just note one data point from the other thread I have open: a good part of the "catastrophically bad in many cases" is the metapage tuple counter serialising every insert on one buffer, and that looks removable. Inserts stop touching the metapage on the common path and hash then scales like btree on a concurrent insert workload in my measurements. That doesn't change your conclusion about large-key handling, but it does move some of the "performs badly" into "performed badly". > 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. No disagreement that that would have been the better design. It's not where we are, though, and ripping out a shipped, WAL-logged, user-visible AM is its own multi-release project. Which leaves the thing this thread actually needs a decision on, independent of hash's long-term fate: master faults a standby under wal_consistency_checking='hash' today. The one-line fix (skip the full-page image for a REGBUF_NO_CHANGE block, which contradicts the flag's own contract to take) stops that and Michael's OK with it for v17+. You'd said you'd rather master wait for the proper hash rework. I'm fine either way, but if master isn't getting the flag-level fix now, I'd like the rework to be the tracked item for master rather than a someday, the crash is live on master. So: flag fix in master now plus rework as follow-up, or rework-only for master? I'll build whichever, I just don't want it to stall into neither. best, -greg
