| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Greg Smith <gsmith(at)gregsmith(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Alan Li <ali(at)truviso(dot)com> |
| Subject: | Re: 8.4 open item: copy performance regression? |
| Date: | 2009-06-21 15:31:54 |
| Message-ID: | 12404.1245598314@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> 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:
Were you testing with a temp table? The lack of XLogInsert in your
profile is striking. Stefan's results upthread had it at the top,
and I got more or less the same thing here (didn't keep my numbers
unfortunately).
> 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.
The potential for deadlock seems sufficient reason not to do that.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stefan Kaltenbrunner | 2009-06-21 15:35:05 | Re: 8.4 open item: copy performance regression? |
| Previous Message | Robert Haas | 2009-06-21 15:16:35 | Re: 8.4 open item: copy performance regression? |