Awhile back, Chris Marcellino <[EMAIL PROTECTED]> wrote:
> I searched through the archives and I can't find a mention of why the
> posix_sema code was written for Darwin.
> I assume it is because before Darwin 6.0/Mac OS X 10.2 there was not
> kernel support for SysV semaphores.
> If this is in fact the case, I have a trivial patch to conditionally
> enable SysV semaphores based on the OS release:
This seems to have slipped through the cracks --- apologies, but IIRC
core were a bit distracted with security issues right around then.
I've tried this patch on my Mac laptop, and while it seems to work as
advertised in terms of not eating a boatload of file descriptors,
I was disturbed to find that it seems consistently a couple percent
slower than the POSIX-sema code according to pgbench. I get numbers
like these:
SYSV POSIX
pgbench -c 10 -t 1000 104.4 tps 106.5 tps
pgbench -C -c 10 -t 1000 25.73 tps 26.07 tps
The numbers jump around a good deal from run to run, but it seemed that
the SYSV code was always a bit slower in two comparable runs.
Test conditions: PG CVS HEAD as of today, fully up-to-date OS X 10.4.9
running on a 1.33GHZ 12" Al Powerbook, all kernel and PG settings
default except for fsync off, pgbench initialized with -s 10. This of
course has nothing to do with real-world database performance, but I was
at least hoping to confirm that there wouldn't be any performance
penalty for switching to SYSV semas. Seems like there is. Comments?
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
