On Tue, Jun 25, 2024 at 6:04 AM Tomas Vondra <tomas.von...@enterprisedb.com> wrote: > Yeah, definitely needs comment explaining this. > > I admit those numbers are pretty arbitrary primes, to implement a > trivial hash function. That was good enough for a PoC patch, but maybe > for a "proper" version this should use a better hash function. It needs > to be fast, and maybe it doesn't matter that much if it's not perfect.
Right. My guess is that if we try too hard to make the hash function good, there will be a performance hit. Unlike, say, strings that come from the user, we have no reason to believe that relfilenumbers will have any particular structure or pattern to them, so a low-quality, fast function seems like a good trade-off to me. But I'm *far* from a hashing expert, so I'm prepared for someone who is to tell me that I'm full of garbage. > I don't think I've heard the term "partially-associative cache" before > That's an excellent question. I don't know. > > I agree 64 groups is pretty arbitrary, and having 1024 may not be enough > even with a modest number of partitions. When I was thinking about using > a higher value, my main concern was that it'd made the PGPROC entry > larger. Each "fast-path" group is ~72B, so 64 groups is ~4.5kB, and that > felt like quite a bit. > > But maybe it's fine and we could make it much larger - L3 caches tend to > be many MBs these days, although AFAIK it's shared by threads running on > the CPU. > > I'll see if I can do some more testing of this, and see if there's a > value where it stops improving / starts degrading, etc. Sounds good. -- Robert Haas EDB: http://www.enterprisedb.com
