On Sun, Jun 21, 2009 at 6:48 AM, Stefan
Kaltenbrunner<stefan@kaltenbrunner.cc> wrote:
> So I do think that IO is in fact not too significant for this kind of
> testing and we still have ways to go in terms of CPU efficiency in COPY.
It would be interesting to see some gprof or oprofile output from that
test. I went back and dug up the results that I got when I profiled
this patch during initial development, and my version of the patch
applied, the profile looked like this on my system:
% cumulative self self totaltime seconds seconds calls s/call s/call name14.48
0.85 0.85 1 0.85 5.47 DoCopy10.05 1.44 0.59 10000001 0.00 0.00 CopyReadLine 5.62
1.77 0.33 10000039 0.00 0.00 PageAddItem 5.11 2.07 0.30 10400378 0.00 0.00
LWLockRelease4.68 2.35 0.28 10000013 0.00 0.00 heap_insert 4.34 2.60 0.26 10000012 0.00
0.00 heap_formtuple 3.83 2.83 0.23 10356158 0.00 0.00 LWLockAcquire 3.83 3.05 0.23
10000054 0.00 0.00 MarkBufferDirty 3.32 3.25 0.20 10000013 0.00 0.00
RelationGetBufferForTuple3.07 3.43 0.18 10000005 0.00 0.00 pg_verify_mbstr_len 2.90 3.60
0.1710000002 0.00 0.00 CopyGetData 2.73 3.76 0.16 20000030 0.00 0.00 enlargeStringInfo 2.73
3.92 0.16 20000014 0.00 0.00 pq_getbytes 2.04 4.04 0.12 10000000 0.00 0.00
InputFunctionCall
...but this might not be very representative, since I think I may have
tested it on a single-column table. It would be interesting to see
some other results.
Simon had the idea of further improving performance by keeping the
current buffer locked (this patch just kept it pinned, but not
locked), but I didn't see an obvious clean design for that. Heikki
also had a patch for speeding up copy, but it got dropped for 8.4 due
to time constraints.
...Robert
