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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
