Re: Thousands of semops for every i/o

From: "Jeffrey W(dot) Baker" <jwbaker(at)acm(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Thousands of semops for every i/o
Date: 2003-06-10 21:15:58
Message-ID: 1055279758.29948.13.camel@heat
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-patches

On Mon, 2003-06-09 at 23:08, Tom Lane wrote:
> "Jeffrey W. Baker" <jwbaker(at)acm(dot)org> writes:
> > This is the strace of a process which is deleting rows from four tables,
> > inside a transaction, one row at a time. There are a lot of semops for
> > every i/o. There are about 30 connections to this database currently.
> > I thought deletes in a transaction just flew along in Pg, because they
> > simply wrote the deleted transaction ID on the record. It used to work
> > fine in my previous locally-built 7.2 on Debian, but this is 7.2.2 on
> > SuSE Enterprise Server 8.2.
>
> The first thing that comes to mind is that the thing is using SysV
> semaphores as a substitute for spinlocks. If this is on a hardware
> platform that is supposed to have TAS() support in s_lock.h or s_lock.c,
> then it's a configuration or build error. If it's on some heretofore
> unknown platform, you need to write some TAS() code to get decent
> performance.

It looks like a simple change in s_lock.h from

#if defined(__i386__)

to

#if defined(__i386__) || defined(__x86_64__)

Will be necessary for this platform.

Thanks,
jwb

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message John Smith 2003-06-10 21:18:52 increment_by@
Previous Message John Smith 2003-06-10 21:06:08 pg_dumpall error: attribute not found

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2003-06-10 21:24:36 Re: Thousands of semops for every i/o
Previous Message Rod Taylor 2003-06-10 11:42:42 UPDATE ... SET <col> = DEFAULT