Kris Kennaway <[EMAIL PROTECTED]> forwards:
> Yes but there are still a lot of wakeups to be avoided in the current
> System V semaphore code. More specifically, not only do we wakeup all
> the processes waiting on a single semaphore everytime something changes,
> but we also wakeup all processes waiting on *any* of the semaphore in
> the semaphore *set*, whatever the reason we're sleeping.
Ohhhh ... *that's* the problem. Ugh. Although we have a separate
semaphore for each PG backend, they're grouped into semaphore sets
(I think 16 active semaphores per set). So a wakeup intended for one
process would uselessly send up to 15 others through the semop code.
The only thing we could do to fix that from our end would be to use
a smaller sema-set size on *BSD platforms. Is the overhead per sema set
small enough to make this a sane thing to do? Will we be likely to
run into system limits on the number of sets?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
