| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Manfred Spraul <manfred(at)colorfullife(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: semtimedop instead of setitimer/semop/setitimer |
| Date: | 2003-09-19 23:23:03 |
| Message-ID: | 11746.1064013783@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
Manfred Spraul <manfred(at)colorfullife(dot)com> writes:
> I've noticed that postgres strace output contains long groups of
> setitimer/semop/setitimer.
> Just FYI: semtimedop is a special syscalls that implements a semop with
> a timeout. It was added just for the purpose of avoiding the setitimer
> calls.
> I know that it's supported by Solaris and recent Linux versions, I'm not
> sure about other operating systems.
I am ;-). We could not rely on using it.
> Has anyone tried to use it?
It would require a fairly messy crossing of platform-dependent with
platform-independent code. Can we see some proof that there's a useful
speedup possible before we think about this?
AFAIK, semops are not done unless we actually have to yield the
processor, so saving a syscall or two in that path doesn't sound like a
big win. I'd be more interested in asking why you're seeing long series
of semops in the first place.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jenny Zhang | 2003-09-19 23:26:54 | Re: osdl-dbt3 run results - puzzled by the execution |
| Previous Message | scott.marlowe | 2003-09-19 23:10:07 | Re: PostgreSQL not ACID compliant? |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2003-09-19 23:31:27 | Re: pgsql-server/src/backend catalog/index.c comma ... |
| Previous Message | Hiroshi Inoue | 2003-09-19 23:06:55 | Re: pgsql-server/src/backend catalog/index.c comma ... |