Re: performance: use pread instead of lseek+read - Mailing list pgsql-patches

From Manfred Spraul
Subject Re: performance: use pread instead of lseek+read
Date
Msg-id 3E5B0EA1.6050805@colorfullife.com
Whole thread Raw
In response to Re: performance: use pread instead of lseek+read  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: performance: use pread instead of lseek+read  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: performance: use pread instead of lseek+read
Next
From: Karel Zak
Date:
Subject: Re: to_char PL/MI fix