Bruce Momjian wrote:
write 0.000360
write fsync 0.001391
write, close fsync 0.001308
open o_fsync, write0.000924
That's 1 milliseconds vs. 1.3 milliseconds. Neither value is realistic -
I guess the hw cache on and the os doesn't issue cache flush
Tom Lane wrote:
[EMAIL PROTECTED] writes:
I could certainly do some testing if you want to see how DBT-2 does.
Just tell me what to do. ;)
Just do some runs that are identical except for the wal_sync_method
setting. Note that this should not have any impact on SELECT
performance, only
[EMAIL PROTECTED] wrote:
Compare file sync methods with one 8k write:
(o_dsync unavailable)
open o_sync, write 6.270724
write, fdatasync13.275225
write, fsync, 13.359847
Odd. Which filesystem, which kernel? It seems fdatasync is broken and
Neil wrote:
. In any case, the futex patch
uses the Linux 2.6 futex API to implement PostgreSQL spinlocks.
Has anyone tried to replace the whole lwlock implementation with
pthread_rwlock? At least for Linux with recent glibcs, pthread_rwlock is
implemented with futexes, i.e. we would get a
Tom Lane wrote:
Manfred Spraul [EMAIL PROTECTED] writes:
Has anyone tried to replace the whole lwlock implementation with
pthread_rwlock? At least for Linux with recent glibcs, pthread_rwlock is
implemented with futexes, i.e. we would get a fast lock handling without
os specific hacks
Mark Wong wrote:
Here are some other details, per Manfred's request:
Linux 2.6.8.1 (on a gentoo distro)
How complicated are Tom's test scripts? His immediate reply was that I
should retest with Fedora, to rule out any gentoo bugs.
I have a dual-cpu system with RH FC, I could use it for
Tom Lane wrote:
Manfred Spraul [EMAIL PROTECTED] writes:
Tom Lane wrote:
The bigger problem here is that the SMP locking bottlenecks we are
currently seeing are *hardware* issues (AFAICT anyway). The only way
that futexes can offer a performance win is if they have a smarter way
Mark Wong wrote:
Pretty, simple. One to load the database, and 1 to query it. I'll
attach them.
I've tested it on my dual-cpu computer:
- it works, both cpus run within the postmaster. It seems something your
gentoo setup is broken.
- the number of context switch is down slightly, but not
Mark Wong wrote:
I've heard that simply linking to the pthreads libraries, regardless of
whether you're using them or not creates a significant overhead. Has
anyone tried it for kicks?
That depends on the OS and the functions that are used. The typical
worst case is buffered IO of single
