Re: Using multi-row technique with COPY - Mailing list pgsql-hackers

From Jim C. Nasby
Subject Re: Using multi-row technique with COPY
Date
Msg-id 20051129004435.GR78939@pervasive.com
Whole thread Raw
In response to Using multi-row technique with COPY  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
On Sun, Nov 27, 2005 at 07:44:55PM +0000, Simon Riggs wrote:
> not have any unique indexes or row triggers. It should be possible to
> take advantage of this automatically when those requirements are met,
> without any new options. Just as it was with Seq Scans, this is worth
> about 10% reduction in CPU for a COPY FROM.
<snip> 
> FSM access would need to change slightly to allow for whole-block-only
> requests to be made for heaps, without damaging the average row length
> calculation. It might be simpler to ignore FSM entirely?

Does that mean that this fast copy would end up not re-using space on
pages that have space available? ISTM that's something users would want
to be able to over-ride. In fact, it seems like it shouldn't be a
default behavior...
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: gprof SELECT COUNT(*) results
Next
From: Greg Stark
Date:
Subject: Re: Hashjoin startup strategy (was Re: Getting different number of results when using hashjoin on/off)