Hi Andres,
Using pread instead of lseek+read halfes the syscalls.
I really don't understand what you are fighting here ..
Sure, there's some overhead. And as I said upthread, I'm much less
against this change than Tom. What I'm saying is that your benchmarks
haven't shown a benefit in a meaningful way, so I don't think I can
agree with
"Well, my point remains that I see little value in messing with
long-established code if you can't demonstrate a benefit that's clearly
above the noise level."
I have done lots of benchmarking over the last days on a massive box, and I
can provide numbers that I think show that the impact can be significant.
since you've not actually shown that the impact is above the noise level
when measured with an actual postgres workload.
I can follow that.
So real prove cannot be done with FIO, but "actual PG workload".
Synthetic PG workload or real world production workload?
Also: rgd the perf profiles from production that show lseek as #1 syscall.
You said it wouldn't be prove either, because it only shows number of
syscalls, and though it is clear that millions of syscalls/sec do come
with overhead, it is still not showing "above noise" level relevance
(because PG is such a CPU hog in itself anyways;)
So how would I do a perf profile that would be acceptable as prove?
Maybe I can expand our
https://gist.github.com/oberstet/ca03d7ab49be4c8edb70ffa1a9fe160c
profiling function.
Cheers,
/Tobias
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
