I did the patch, but to my surprise, the results weren't so good.
Despite that claiming a tiny improvement in performance, I didn't expect any slowdown. I put a counter in pg_regress.c, summing the results of each test and did it three times for HEAD and for the patch. Some tests were better, but others were bad.
Tests comments per example, show 180%, combocid 174%, dbize 165%, xmlmap 136%, lock 134%.
...
...
So I'm posting the patch here, merely as an illustration of my findings. Perhaps someone with a better understanding of the process of translating C to asm can have an explanation.
Is it worth it to change only where there has been improvement?
My guess is that your hypothetical performance improvement has been completely swamped by the natural variations of each run.
For example,
drop_if_exists
115
84
83
94
138
63
57
86
109,30%
Those numbers are all over the place, so I doubt the results are really saying anything at all about what is better/worse, because I think you have zero chance to notice a couple of nanoseconds of improvement within the noise when each run is varying from 57 to 138 ms.
IMO the only conclusion you can draw from your results is that any performance gain is too small to be observable.
Thanks Peter for your explanations.
I can conclude then that the test results are not a reference for performance/regression.
So the patch serves as a refactoring, without any further indication.
