I rebuilt with these changes and am seeing a 30-40% improvement in average performance
for
my high-contention high-volume copy case. I still need to do some more testing, but
this really
seems to help.
Thanks a lot Tom!
Tom Lane wrote:
>
> I have committed some changes into development sourc
> > 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 doe
Tom Lane wrote:
>
> "Mikheev, Vadim" <[EMAIL PROTECTED]> 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 o
"Mikheev, Vadim" <[EMAIL PROTECTED]> 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
John Coers <[EMAIL PROTECTED]> writes:
> I am trying to figure out what is slowing down multiple concurrent COPY
> commands to my database and all I see is lots of semops.
Are you talking about concurrent copies into the same table? That would
suffer a lot of short-term lock interference, no dou
