On Mon, Oct 12, 2026 at 9:02 PM Dhruv Aron <[email protected]> wrote:
> On Mon, Oct 12, 2026 at 1:40 PM Alexandre Felipe < > [email protected]> wrote: > >> 1. mod vs bitwise and >> Instead of computing [hashcode % num_buckets] you could save >> bucket_mask = num_bucket - 1, and do hashcode & bucket_mask. >> >> 2. the 1.5 factor >> On my first review I pointed out that in one specific test for >> shared_buffers >> as a power of two the number of buckets in your patch ended up being half >> as many as the previous version (maybe that is the correct way to go). >> Or maybe you want at least to rewrite that line using integer arithmetic. >> > > Regarding 1: Yes, the bitwise-AND should work and would most likely be > more performant than using modulo. > Regarding 2: Since the patched table does not allow inserting a new entry > before deleting the stale entry for the same slot, there was no need to > additionally allocate NUM_BUFFER_PARTITIONS buckets (the reason why the > number of buckets for the master code was rounded up to 0x8000 instead of > 0x4000 for 128MB SB). Could you elaborate more on what you mean by > '[rewriting] that line using integer arithmetic?' > 1.5 * num_bucket implicitly casts to floating point, and later back to integer, that was not meant to be permanent. A safer option would be (num_buckets | (num_buckets >> 1)), no wrap-around if some day this gets increased to UINT_MAX. Or simply num_buckets, without multiplication at all. Regards, Alexandre >
