the PGconn buffer to the PGresult
structure to their buffers. The callback keeps the slowest guy on the
team...on the bench.
Kyle Gearhart
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/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 a quick look through the code.
> It'd be interesting to see how things change if you eliminate the filler
> column from the SELECT.
Traces
From: Tom Lane [mailto:t...@sss.pgh.pa.us]:
> Kyle Gearhart writes:
>> The guts of pqRowProcessor in libpq does a good bit of work to maintain the
>> internal data structure of a PGresult. There are a few use cases where the
>> caller doesn't need the ability to ac
QrowProcessorCB)(PGresult*, const PGdataValue*, int col_count, void
*user_data);
My initial testing shows a significant performance improvement. I'd like some
opinions on this before wiring up a performance proof and updating the
documentation for a formal patch submission.
Kyle Gearhart
