Re: Seq scans roadmap

Hi All,

COPY/INSERT are also bottlenecked on record at a time insertion into  
heap, and in checking for pre-insert trigger, post-insert trigger and  
constraints.

To speed things up, we really need to special case insertions without  
triggers and constraints, [probably allow for unique constraints],  
and make these insertions to go into heap N tuples at a time. With  
this change, comes the benefit of optimizing REDO log to log multiple  
inserts or even logging a whole new heap page that gets filled in a  
single WAL record.

Those with triggers and other constraints would still have to go in  
one at a time because of the trigger/constraints semantics.

It seems to me that dirty pages should be written out by the bg  
writer instead of circumventing it using ring buffer. If it is slow,  
we should change bg writer.

-cktan

On May 12, 2007, at 8:42 AM, Luke Lonergan wrote:

> Hi Simon,
>
> On 5/12/07 12:35 AM, "Simon Riggs" <simon@enterprisedb.com> wrote:
>
>> I'm slightly worried that the results for COPY aren't anywhere  
>> near as
>> good as the SELECT and VACUUM results. It isn't clear from those  
>> numbers
>> that the benefit really is significant.
>
> COPY is bottlenecked on datum formation and format translation with  
> very low
> performance, so I don't think we should expect the ring buffer to  
> make much
> of a dent.
>
> - Luke
>