COPY/INSERT are also bottlenecked on record at a time insertion into
heap, and in checking for pre-insert trigger, post-insert trigger and
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.
On May 12, 2007, at 8:42 AM, Luke Lonergan wrote:
On 5/12/07 12:35 AM, "Simon Riggs" <[EMAIL PROTECTED]> wrote:
I'm slightly worried that the results for COPY aren't anywhere
good as the SELECT and VACUUM results. It isn't clear from those
that the benefit really is significant.
COPY is bottlenecked on datum formation and format translation with
performance, so I don't think we should expect the ring buffer to
of a dent.
---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at