Re: performance: use pread instead of lseek+read

From: Manfred Spraul <manfred(at)colorfullife(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: performance: use pread instead of lseek+read
Date: 2003-02-24 21:52:30
Message-ID: 3E5A941E.3060901@colorfullife.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Tom Lane wrote:

>Manfred Spraul <manfred(at)colorfullife(dot)com> writes:
>
>
>>What about removing lseek entirely and using the p{read,write}?
>>
>>
>
>Portability.
>
>$ man pread
>No manual entry for pread.
>
Which OS? google finds manpages for Tru64 4.0, HP UX 11i, solaris 8, aix 4.3
Linux has it since 2.2, FreeBSD at least since 4.0, it's even listed in
the SVR-4 emulation of FreeBSD.

>$
>
>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. A kernel
must perform quite a lot of parameter validation and synchronization -
think about a multithreaded app where close and lseek could race.

>
>
>>Attached is a patch vs the cvs tree.
>>It seems to work - 7.3.2 with the patch applied passes the regression
>>
>>
>
>Can you measure any performance benefit?
>
>
What would be an interesting benchmark?
If you want a microbenchmark: lseek+read(,,8192) is around 10% slower
than pread(,,,8192) with hot cpu caches on my Celeron Mobile Laptop.
Linux-2.4.20.

Read-ahead is impossible to answer without looking at the sources. Linux
does readahead, actually read is implemented as pread(,,,file->f_pos).

--
Manfred

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2003-02-24 23:41:23 Re: performance: use pread instead of lseek+read
Previous Message Ross J. Reedstrom 2003-02-24 21:34:57 Re: Simplifying timezone support