Re: Thousands of semops for every i/o
От | Jeffrey W. Baker |
---|---|
Тема | Re: Thousands of semops for every i/o |
Дата | |
Msg-id | 1055279758.29948.13.camel@heat обсуждение исходный текст |
Ответ на | Re: Thousands of semops for every i/o (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Thousands of semops for every i/o
Re: Thousands of semops for every i/o Re: Thousands of semops for every i/o |
Список | pgsql-general |
On Mon, 2003-06-09 at 23:08, Tom Lane wrote: > "Jeffrey W. Baker" <jwbaker@acm.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
В списке pgsql-general по дате отправления: