Hi Andres,

> I don't think it's a good idea to introduce new simplehash infrastructure
as
> part of this larger change.

I am submitting the change I did before on simplehash for empty entry
detection.

> You also haven't documented the new stuff.

What and where I was supposed to document?

01 the change I did before, 02 I applied it to refcount in bufmgr.
Exploring a bit more the code base, 03 removes status from nodeMemoize
04 remove status from pg_rewind/filemap.c
05 was a bit trickier because InvalidBlockNumber is not 0, then I had to
make entries empty after allocation that uses memset 0 by default.

I grepped for a list and there are 21 files in total so I will stop here.


> In my benchmarks allowing vectorization helped a decent amount in real
> queries, because it does away with all the branch misses.

Interesting, did you compile with the default configuration?
I used gcc11 (a bit old I know) and and yes, it remove some branches
but still use a loop with cmove (conditional copy), in some cases it unrolls
but still uses cmove for each entry (the machine I tested  is quite feature
rich
e.g. avx512cd avx512bw avx512vl avx512_vnni.

So I am wondering if the impact I see is not the same impact as you see.

If we go for vectorisation we could do a vectorized loop
e.g. 16 iterations on 16 x 32-bit vectors with early exit.
but that would inevitably make the few entries case slightly slower.


Do you have any other localised issue like this that could be worth looking
into?

Regards,
Alexandre

Attachment: v3-0004-Use-null-pointer-as-an-empty-marker.patch
Description: Binary data

Attachment: v3-0001-Custom-simplehash-empty-value-detection.patch
Description: Binary data

Attachment: v3-0003-Use-NULL-key-as-empty-in-nodeMemoize.c.patch
Description: Binary data

Attachment: v3-0005-Use-InvalidBlockNumber-as-empty-marker.patch
Description: Binary data

Attachment: v3-0002-Use-InvalidBuffer-to-indicate-empty-slot.patch
Description: Binary data

Reply via email to