Re: [HACKERS] libpq Alternate Row Processor

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: [HACKERS] libpq Alternate Row Processor
Дата
Msg-id CAHyXU0z0tQ9OhiaN47gm6GfF93xUrmr0E+KDSyoiGmr1CT6dqQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] libpq Alternate Row Processor  (Kyle Gearhart <kyle.gearhart@indigohill.io>)
Ответы Re: [HACKERS] libpq Alternate Row Processor  (Kyle Gearhart <kyle.gearhart@indigohill.io>)
Список 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 по дате отправления:

Предыдущее
От: Fabien COELHO
Дата:
Сообщение: Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands:\quit_if, \quit_unless)
Следующее
От: Brad DeJong
Дата:
Сообщение: Re: [HACKERS] Small improvement to parallel query docs