On Wed, Feb 1, 2023 at 2:49 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > It's precisely because you want to analyze it in the same terms > as range/list partitioning that we have these issues. Or we could > have built it on some other infrastructure than hash index opclasses > ... but we didn't do that, and now we have a mess. I don't see a way > out other than relaxing the guarantees about how hash partitioning > works compared to the other kinds.
I suspect that using hash index opclasses was the right design -- sticking to the same approach to hashing seems valuable. I agree with your overall conclusion, though, since it doesn't seem sensible to allow hashing behavior to ever be anything greater than an implementation detail. On general principle. What happens when a hash function is discovered to have a huge flaw, as happened a couple of times before now? It's just the same with collations, where a particular collation shouldn't be expected to have perfectly stable behavior across a dump and reload. While admitting that possibility does open the door to problems, in particular problems when range partitioning is in use, those problems at least make sense. And they probably won't come up very often -- collation updates don't often contain enormous gratuitous differences that are liable to create dump/reload hazards with range partitioning. It is the least worst approach, overall. In theory, and in practice. -- Peter Geoghegan
