Re: Seq scans roadmap - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Seq scans roadmap
Date
Msg-id 87bqgvz44y.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Seq scans roadmap  ("Zeugswetter Andreas ADI SD" <ZeugswetterA@spardat.at>)
Responses Re: Seq scans roadmap  ("Zeugswetter Andreas ADI SD" <ZeugswetterA@spardat.at>)
List pgsql-hackers
"Zeugswetter Andreas ADI SD" <ZeugswetterA@spardat.at> writes:

>> Are you filling multiple buffers in the buffer cache with a 
>> single read-call?
>
> yes, needs vector or ScatterGather IO.

I would expect that to get only moderate improvement. To get the full benefit
I would think you would want to either fire off a separate thread to do the
read-ahead, use libaio, or funnel the read-ahead requests to a separate thread
like our bgwriter only it would be a bgreader or something like that.

>> The OS should be doing readahead for us 
>> anyway, so I don't see how just issuing multiple ReadBuffers 
>> one after each other helps.
>
> Last time I looked OS readahead was only comparable to 32k blocked reads.
> 256k blocked reads still perform way better. Also when the OS is confronted
> with an IO storm the 256k reads perform way better than OS readahead.

Well that's going to depend on the OS. Last I checked Linux's readahead logic
is pretty straightforward and doesn't try to do any better than 32k readahead
and is easily fooled. However I wouldn't be surprised if that's changed. 

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: Managing the community information stream
Next
From: Lukas Kahwe Smith
Date:
Subject: Re: Managing the community information stream