Re: [HACKERS] libpq Alternate Row Processor - Mailing list pgsql-hackers

From Kyle Gearhart
Subject Re: [HACKERS] libpq Alternate Row Processor
Date
Msg-id BLUPR14MB0162956D2C5887B726D5A7F8FA590@BLUPR14MB0162.namprd14.prod.outlook.com
Whole thread Raw
In response to Re: [HACKERS] libpq Alternate Row Processor  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: [HACKERS] libpq Alternate Row Processor  (Merlin Moncure <mmoncure@gmail.com>)
Re: [HACKERS] libpq Alternate Row Processor  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers
On 2/9/17 7:15 PM, Jim Nasby wrote:
> Can you run a trace to see where all the time is going in the single row case? I don't see an obvious time-suck with
aquick look through the code. It'd be interesting to see how things change if you eliminate the filler column from the
SELECT.

Traces are attached, these are with callgrind.

profile_nofiller.txt: single row without filler column
profile_filler.txt: single row with filler column
profile_filler_callback.txt: callback with filler column

pqResultAlloc looks to hit malloc pretty hard.  The callback reduces all of that to a single malloc for each row.

Without the filler, here is the average over 11 runs:
        Real    user    sys
Callback    .133    .033    .035
Single Row    .170    .112    .029

For the callback case, it's slightly higher than the prior results with the filler column.

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

Attachment

pgsql-hackers by date:

Previous
From: Bernd Helmle
Date:
Subject: Re: [HACKERS] LWLock optimization for multicore Power machines
Next
From: Amit Kapila
Date:
Subject: Re: [HACKERS] Write Ahead Logging for Hash Indexes