Re: COPY locking

I have committed some changes into development sources that should
reduce contention overhead when multiple backends are inserting into the
same table. If you're interested in trying it out, you could pull the
latest sources from our CVS server, or try back-patching the changes
into 7.1.*. The relevant changes are in these files:

2001-05-12 15:58 tgl

* src/: backend/access/heap/heapam.c, backend/access/heap/hio.c,
backend/storage/buffer/bufmgr.c, backend/storage/buffer/localbuf.c,
include/storage/bufmgr.h: Modify RelationGetBufferForTuple() so
that we only do lseek and lock when we need to move to a new page;
as long as we can insert the new tuple on the same page as before,
we only need LockBuffer and not the expensive stuff. Also, twiddle
bufmgr interfaces to avoid redundant lseeks in
RelationGetBufferForTuple and BufferAlloc. Successive inserts now
require one lseek per page added, rather than one per tuple with
several additional ones at each page boundary as happened before.
Lock contention when multiple backends are inserting in same table
is also greatly reduced.

2001-05-10 16:38 tgl

* src/: backend/commands/sequence.c,
backend/storage/buffer/bufmgr.c, backend/storage/smgr/md.c,
backend/storage/smgr/mm.c, backend/storage/smgr/smgr.c,
include/storage/smgr.h: Avoid unnecessary lseek() calls by cleanups
in md.c. mdfd_lstbcnt was not being consulted anywhere, so remove
it and remove the _mdnblocks() calls that were used to set it.
Change smgrextend interface to pass in the target block number (ie,
current file length) --- the caller always knows this already,
having already done smgrnblocks(), so it's silly to do it over
again inside mdextend. Net result: extension of a file now takes
one lseek(SEEK_END) and a write(), not three lseeks and a write.

regards, tom lane