From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Zeugswetter Andreas ADI SD" <ZeugswetterA(at)spardat(dot)at> |
Cc: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, "Luke Lonergan" <LLonergan(at)greenplum(dot)com>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>, "Jeff Davis" <pgsql(at)j-davis(dot)com>, "Simon Riggs" <simon(at)enterprisedb(dot)com> |
Subject: | Re: Seq scans roadmap |
Date: | 2007-05-08 16:11:57 |
Message-ID: | 87bqgvz44y.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Zeugswetter Andreas ADI SD" <ZeugswetterA(at)spardat(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Lukas Kahwe Smith | 2007-05-08 16:24:49 | Re: Managing the community information stream |
Previous Message | Jim Nasby | 2007-05-08 16:03:58 | Re: Managing the community information stream |