Re: Seq scans roadmap

Поиск
Список
Период
Сортировка
От Gregory Stark
Тема Re: Seq scans roadmap
Дата
Msg-id 87bqgvz44y.fsf@oxford.xeocode.com
обсуждение исходный текст
Ответ на Re: Seq scans roadmap  ("Zeugswetter Andreas ADI SD" <ZeugswetterA@spardat.at>)
Ответы Re: Seq scans roadmap  ("Zeugswetter Andreas ADI SD" <ZeugswetterA@spardat.at>)
Список 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 по дате отправления:

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: Managing the community information stream
Следующее
От: Lukas Kahwe Smith
Дата:
Сообщение: Re: Managing the community information stream