Re: Using multi-row technique with COPY

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Using multi-row technique with COPY
Date: 2005-11-29 00:44:35
Message-ID: 20051129004435.GR78939@pervasive.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2005-11-29 01:39:22 Re: Allow an alias for the target table in UPDATE
Previous Message Tom Lane 2005-11-29 00:35:45 Re: gprof SELECT COUNT(*) results