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(at)enterprisedb(dot)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
>