Re: Why we are going to have to go DirectIO

Поиск
Список
Период
Сортировка
От KONDO Mitsumasa
Тема Re: Why we are going to have to go DirectIO
Дата
Msg-id 52A7E372.7060409@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: Why we are going to have to go DirectIO  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
(2013/12/11 10:25), Tom Lane wrote:
> Jeff Janes <jeff.janes@gmail.com> writes:
>> On Tue, Dec 3, 2013 at 11:39 PM, Claudio Freire <klaussfreire@gmail.com>wrote:
>>> Problem is, Postgres relies on a working kernel cache for checkpoints.
>>> Checkpoint logic would have to be heavily reworked to account for an
>>> impaired kernel cache.
> 
>> I don't think it would need anything more than a sorted checkpoint.
> 
> Nonsense.  We don't have access to the physical-disk-layout information
> needed to do reasonable sorting;
OS knows physical-disk-layout which is under following.
> [mitsu-ko@ssd ~]$ filefrag -v .bashrc
> Filesystem type is: ef53
> File size of .bashrc is 124 (1 block, blocksize 4096)
>  ext logical physical expected length flags
>    0       0 15761410               1 eof
> .bashrc: 1 extent found
If we have to know this information, we can get physical-disk-layout whenever.

> to say nothing of doing something
> intelligent in a multi-spindle environment, or whenever any other I/O
> is going on concurrently.
IO scheduler in OS knows it best. So I think BufferedIO is faster than DirectIO
in general situations.

Regards,
--
Mitsumasa KONDO
NTT Open Source Software Center



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: [PATCH] Add transforms feature
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: plpgsql_check_function - rebase for 9.3