In article <[EMAIL PROTECTED]>, "Jim C. Nasby" <[EMAIL PROTECTED]> 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. ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
