On Sat, 28 May 2022 at 02:51, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Given David's results in the preceding message, I don't think I am.
> A scheme like this would add more arithmetic and at least one more
> indirection to GetMemoryChunkContext(), and we already know that
> adding even a test-and-branch there has measurable cost.
I also ran the same tests on my patch to binary search for the
generation block and the performance is worse than with the
MemoryContextLink patch, albeit, limited to generation contexts only.
Also disheartening. See attached bsearch_gen_blocks.txt
I decided to run some more extensive benchmarking with the 10GB table
with varying numbers of BIGINT columns from 6 up to 14. 6 columns
means 64-byte pallocs in the generation context and 14 means 128
bytes. Once again, I tested work_mem values starting at 4MB and
doubled that each test until I got to 16GB. The results are attached
both in chart format and I've also included the complete results in a
spreadsheet along with the script I ran to get the results.
The results compare PG14 @ 0adff38d against master @ b3fb16e8b. In
the chart, anything below 100% is a performance improvement over PG14
and anything above 100% means PG15 is slower. You can see there's
only the 64-byte / 64MB work_mem test that gets significantly slower
and that there are only a small amount of other tests that are
slightly slower. Most are faster and on average PG15 takes 90% of the
time that PG14 took.
Likely it would have been more relevant to have tested this against
master with 40af10b57 reverted. I'm running those now.
David
