From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
Cc: | coers(at)intrinsity(dot)com, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: COPY locking |
Date: | 2001-05-10 20:45:54 |
Message-ID: | 24629.989527554@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> writes:
> access/heap/hio.c:RelationGetBufferForRelation() uses LockPage
> (ie lmgr -> semops) to syncronize table extending.
But no semop should occur unless somebody is actually blocking on
the lock. John's trace only showed one active backend, so I figured
that there shouldn't be any blockage.
> Probably we could
> optimize this somehow, but allocation of new page in bufmgr is
> horrible and that's why we have locks in hio.c from the beginning.
See later message about eliminating lseeks --- I think we should be
able to avoid doing this lock for every single tuple, as it does now,
and only do it when we need to allocate a new page.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Laurent Duperval | 2001-05-10 20:46:18 | How to create a trigger |
Previous Message | Bruce Momjian | 2001-05-10 20:27:48 | Re: NAMEDATALEN |