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

From Merlin Moncure
Subject Re: [HACKERS] libpq Alternate Row Processor
Date
Msg-id CAHyXU0z0tQ9OhiaN47gm6GfF93xUrmr0E+KDSyoiGmr1CT6dqQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] libpq Alternate Row Processor  (Kyle Gearhart <kyle.gearhart@indigohill.io>)
Responses Re: [HACKERS] libpq Alternate Row Processor  (Kyle Gearhart <kyle.gearhart@indigohill.io>)
List pgsql-hackers
On Mon, Feb 13, 2017 at 8:46 AM, Kyle Gearhart
<kyle.gearhart@indigohill.io> wrote:
> 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.

Couldn't that be optimized, say, by preserving malloc'd memory when in
single row mode and recycling it?  (IIRC during the single row mode
discussion this optimization was voted down).

A barebones callback mode ISTM is a complete departure from the
classic PGresult interface.  This code is pretty unpleasant IMO:
acct->abalance = *((int*)PQgetvalue(res, 0, i));
acct->abalance = __bswap_32(acct->abalance);

Your code is faster but foists a lot of the work on the user, so it's
kind of cheating in a way (although very carefully written
applications might be able to benefit).

merlin



pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands:\quit_if, \quit_unless)
Next
From: Brad DeJong
Date:
Subject: Re: [HACKERS] Small improvement to parallel query docs