Re: lseek/read/write overhead becomes visible at scale ..

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