On Tue, Nov 29, 2005 at 01:35:09PM +0100, Harald Fuchs wrote:
> In article <20051129004435.GR78939@pervasive.com>,
> "Jim C. Nasby" <jnasby@pervasive.com> writes:
>
> > 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...
>
> Why not? If you later do INSERT/UPDATE/DELETE, space will get reused
> anyway, and if you don't (i.e. one-time bulk load on a constant
> table), you should afterwards do a VACUUM FULL ANALYZE anyway.
Because the proposal is to fill entirely new pages from COPY, which
pretty much makes FSM useless since you could only use pages in the FSM
if they were entirely empty.
--
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