On Fri, Nov 3, 2017 at 4:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Claudio Freire <klaussfreire@gmail.com> writes:
>> On Thu, Nov 2, 2017 at 11:46 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> BTW, the originally given test case shows no measurable improvement
>>> on my box.
>
>> I did manage to reproduce the original test and got a consistent improvement.
>
> This gave me the idea to memcpy the page into some workspace and then use
> memcpy, not memmove, to put the tuples back into the caller's copy of the
> page. That gave me about a 50% improvement in observed TPS, and a perf
> profile like this:
>
> + 38.50% 38.40% 299520 postmaster postgres [.] compactify_tuples
> + 31.11% 31.02% 241975 postmaster libc-2.12.so [.] memcpy
> + 8.74% 8.72% 68022 postmaster postgres [.] itemoffcompare
> + 6.51% 6.49% 50625 postmaster postgres [.] compactify_tuples_loop
> + 4.21% 4.19% 32719 postmaster postgres [.] pg_qsort
> + 1.70% 1.69% 13213 postmaster postgres [.] memcpy@plt
>
> There still doesn't seem to be any point in replacing the qsort,
> but it does seem like something like the second attached patch
> might be worth doing.
>
> So I'm now wondering why my results seem to be so much different
> from those of other people who have tried this, both as to whether
> compactify_tuples is worth working on at all and as to what needs
> to be done to it if so. Thoughts?
>
> regards, tom lane
>
I'm going to venture a guess that the version of gcc and libc, and
build options used both in the libc (ie: the distro) and postgres may
play a part here.
I'm running with glibc 2.22, for instance, and building with gcc 4.8.5.
I will try and benchmark memcpy vs memmove and see what the
performance difference is there with my versions, too. This may
heavily depend on compiler optimizations that may vary between
versions, since memcpy/memmove tend to be inlined a lot.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
