From 85e2cedf985bfecaf43a18ca17433070f439fb0e Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Thu, 6 Nov 2008 20:51:15 +0000 Subject: Improve bulk-insert performance by keeping the current target buffer pinned (but not locked, as that would risk deadlocks). Also, make it work in a small ring of buffers to avoid having bulk inserts trash the whole buffer arena. Robert Haas, after an idea of Simon Riggs'. --- src/backend/storage/buffer/README | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'src/backend/storage/buffer/README') diff --git a/src/backend/storage/buffer/README b/src/backend/storage/buffer/README index 057f817b7e4..696e5e8c305 100644 --- a/src/backend/storage/buffer/README +++ b/src/backend/storage/buffer/README @@ -1,4 +1,4 @@ -$PostgreSQL: pgsql/src/backend/storage/buffer/README,v 1.14 2008/03/21 13:23:28 momjian Exp $ +$PostgreSQL: pgsql/src/backend/storage/buffer/README,v 1.15 2008/11/06 20:51:14 tgl Exp $ Notes About Shared Buffer Access Rules ====================================== @@ -235,6 +235,10 @@ buffers were sent to the freelist, which was effectively a buffer ring of 1 buffer, resulting in excessive WAL flushing. Allowing VACUUM to update 256KB between WAL flushes should be more efficient. +Bulk writes work similarly to VACUUM. Currently this applies only to +COPY IN and CREATE TABLE AS SELECT. (Might it be interesting to make +seqscan UPDATE and DELETE use the bulkwrite strategy?) + Background Writer's Processing ------------------------------ -- cgit v1.2.3