Re: Seq scans roadmap

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

In response to

Responses

Browse pgsql-hackers by date

  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