Re: index prefetching - Mailing list pgsql-hackers

From Alexandre Felipe
Subject Re: index prefetching
Date
Msg-id CAE8JnxOygarzQpBbBHV+_QZ2A=K01de_iFcn08+D6hNGS3kHPg@mail.gmail.com
Whole thread
In response to Re: index prefetching  (Tomas Vondra <tomas@vondra.me>)
List pgsql-hackers


1) v12-0001-Use-simple-hash-for-PrivateRefCount.patch

- seems like a (mostly) mechanical switch for a different hashtable


 



But Andres slapped me with a question: "Did you try on a real query?"
When I tried on a real query it was a bit slower on the that Andres gave as an
example:
SELECT sum(balance) INTO s FROM uncorrelated WHERE id > 1000 and id < 500000;

It is marginal but consistently slower, I guess it is just the presence of more code
patched: 120.36 - 124.98
master: 116.19 - 118.09
Passing -falign-functionns=64 
patched: 117.82 - 118.88
master: 115.40 - 119.91

Maybe just the presence of more the code, because we don't touch the hash.
I tried with SH_SCOPE `static` or `static pg_noinline` but that doesn't help either.
Assuming one ReadBuffer/ReleaseBuffer per row, we can infer infer that it was
~3ms / 5e5 = 6ns slower.

On micro benchmarking it cuts the gap by half when holding 100 to 1000 buffers.

image.png

If we can accept one more pointer dereference, by having a pointer instead of a static 
array we can reduce by the ramp by 80% (and no, that is not achieved by placing
the bottom of the ramp half way up hehe)


Regards,
Alexandre
Attachment

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Adding REPACK [concurrently]
Next
From: Heikki Linnakangas
Date:
Subject: Re: Better shared data structure management and resizable shared data structures