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 по дате отправления: