On 2/13/17 8:46 AM, Kyle Gearhart wrote:
61,410,901  ???:_int_malloc [/usr/lib64/libc-2.17.so]
38,321,887  ???:_int_free [/usr/lib64/libc-2.17.so]
31,400,139  ???:pqResultAlloc [/usr/local/pgsql/lib/libpq.so.5.10]
22,839,505  ???:pqParseInput3 [/usr/local/pgsql/lib/libpq.so.5.10]
17,600,004  ???:pqRowProcessor [/usr/local/pgsql/lib/libpq.so.5.10]
16,002,817  ???:malloc [/usr/lib64/libc-2.17.so]
14,716,359  ???:pqGetInt [/usr/local/pgsql/lib/libpq.so.5.10]
14,400,000  ???:check_tuple_field_number [/usr/local/pgsql/lib/libpq.so.5.10]
13,800,324  main.c:main [/usr/local/src/postgresql-perf/test]

16,842,303  ???:pqParseInput3 [/usr/local/pgsql/lib/libpq.so.5.10]
14,810,783  ???:_int_malloc [/usr/lib64/libc-2.17.so]
12,616,338  ???:pqGetInt [/usr/local/pgsql/lib/libpq.so.5.10]
10,000,000  ???:pqSkipnchar [/usr/local/pgsql/lib/libpq.so.5.10]
 9,200,004  main.c:process_callback [/usr/local/src/postgresql-perf/test]

Wow, that's a heck of a difference.

There's a ton of places where the backend copies data for no other purpose than to put it into a different memory context. I'm wondering if there's improvement to be had there as well, or whether palloc is so much faster than malloc that it's not an issue. I suspect that some of the effects are being masked by other things since presumably palloc and memcpy are pretty cheap on small volumes of data...
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to