Hi, On 2017-01-25 10:16:32 +0100, Tobias Oberstein wrote: > > > 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".
Right. > Synthetic PG workload or real world production workload? Both might work, production-like has bigger pull, but I'd guess synthetic is good enough. > Also: rgd the perf profiles from production that show lseek as #1 syscall. You'll, depending on your workload, still have a lot of lseeks even if we were to use pread/pwrite because we do lseek(SEEK_END) to get file sizes. > 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;) Yep. > So how would I do a perf profile that would be acceptable as prove? You'd have to look at cpu time, not number of syscalls. IIRC I suggested doing a cycles profile with -g and then using "perf report --children" to see how many cycles are spent somewhere below lseek. I'd also suggest sharing a profile cycles profile, it's quite likely that the overhead is completely elsewhere. - Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers