Hi,
On 2017-01-24 18:37:14 +0100, Tobias Oberstein wrote:
> > assume that it'd get more than swamped with doing actualy work, and with
> > buffering the frequently accessed stuff in memory.
> >
> >
> > > What I am trying to say is: the syscall overhead of doing lseek/read/write
> > > instead of pread/pwrite do become visible and hurt at a certain point.
> >
> > Sure - but the question is whether it's measurable when you do actual
> > work.
>
> The syscall overhead is visible in production too .. I watched PG using perf
> live, and lseeks regularily appear at the top of the list.
Could you show such perf profiles? That'll help us.
> > I'm much less against this change than Tom, but doing artificial syscall
> > microbenchmark seems unlikely to make a big case for using it in
>
> This isn't a syscall benchmark, but FIO.
There's not really a difference between those, when you use fio to
benchmark seek vs pseek.
> > postgres, where it's part of vastly more expensive operations (like
> > actually reading data afterwards, exclusive locks, ...).
>
> PG is very CPU hungry, yes.
Indeed - working on it ;)
> But there are quite some system related effects
> too .. eg we've managed to get down the system load with huge pages (big
> improvement).
Glad to hear it.
> > I'd welcome seeing profiles of that - I'm working quite heavily on
> > speeding up analytics workloads for pg.
>
> Here:
>
> https://github.com/oberstet/scratchbox/raw/master/cruncher/adr_stats/ADR-PostgreSQL-READ-Statistics.pdf
>
> https://github.com/oberstet/scratchbox/tree/master/cruncher/adr_stats
Thanks, unfortunately those appear to mostly have io / cache hit ratio
related stats?
Greetings,
Andres Freund