Re: performance: use pread instead of lseek+read
От | Manfred Spraul |
---|---|
Тема | Re: performance: use pread instead of lseek+read |
Дата | |
Msg-id | 3E5B0EA1.6050805@colorfullife.com обсуждение исходный текст |
Ответ на | Re: performance: use pread instead of lseek+read (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: performance: use pread instead of lseek+read
|
Список | pgsql-patches |
Tom Lane wrote: >Manfred Spraul <manfred@colorfullife.com> writes: > > >>Tom Lane wrote: >> >> >>>It seems unlikely to me that eliminating lseek on some platforms would >>>be worth the hassle of maintaining two code paths. lseek is mighty >>>cheap as system calls go. >>> >>> >>> >>It was considered expensive enough to write a syscall avoidance layer >>that caches the file pointer and skips lseek if fpos==offset. >> >> > >You're missing the point: that layer is mostly there to ensure that we >don't foul up the kernel's readahead recognition for sequential fetches. >It's nice that Linux doesn't care, but Linux is not the only platform >we worry about. > > Do you know that empty lseeks foul up readahead recognition on some OS? If yes, which OS? I've checked FreeBSD and Linux, they don't do it. Actually I would be really surprised if pread would cause readahead problems - for example samba uses it if possible. What about my other questions: - which benchmark would be interesting? - which OS did you use when you got 'no manpage for pread'? -- Manfred
В списке pgsql-patches по дате отправления: