On Thu, Sep 10, 2020 at 9:21 PM vignesh C <vignesh21@gmail.com> wrote:
> > Whether such a micro-optimisation is worth doing is another question.
> Yes, what you suggested can also be done, but even I have the same
> question as you. Because we will reduce just one function call, the
> eof check is present immediately in the function, Should we include
> this or not?
I expect the difference from my suggestion is too small to be measured.
Probably it is not worth changing the already complicated code unless
those changes can achieve something observable.
~~
FYI, I ran a few performance tests BEFORE/AFTER applying your patch.
Perf results for \COPY 5GB CSV file to UNLOGGED table.
perf -a –g <pid>
psql -d test -c "\copy tbl from '/my/path/data_5GB.csv' with (format csv);”
perf report –g
BEFORE
#1 CopyReadLineText = 12.70%, CopyLoadRawBuf = 0.81%
#2 CopyReadLineText = 12.54%, CopyLoadRawBuf = 0.81%
#3 CopyReadLineText = 12.52%, CopyLoadRawBuf = 0.81%
AFTER
#1 CopyReadLineText = 12.55%, CopyLoadRawBuf = 1.20%
#2 CopyReadLineText = 12.15%, CopyLoadRawBuf = 1.10%
#3 CopyReadLineText = 13.11%, CopyLoadRawBuf = 1.24%
#4 CopyReadLineText = 12.86%, CopyLoadRawBuf = 1.18%
I didn't quite know how to interpret those results. It was opposite
what I expected. Perhaps the original excessive CopyLoadRawBuf calls
were so brief they could often avoid being sampled? Anyway, I hope you
have a better understanding of perf than I do and can explain it.
I then repeated/times same tests but without perf
BEFORE
#1 4min.36s
#2 4min.45s
#3 4min.43s
#4 4min.34s
AFTER
#1 4min.41s
#2 4min.37s
#3 4min.34s
As you can see, unfortunately, the patch gave no observable benefit
for my test case.
Kind Regards,
Peter Smith.
Fujitsu Australia
