Re: Prereading using posix_fadvise (was Re: Commitfest patches)

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Prereading using posix_fadvise (was Re: Commitfest patches)
Дата
Msg-id 47ED0D31.7010206@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Prereading using posix_fadvise (was Re: Commitfest patches)  ("Zeugswetter Andreas OSB SD" <Andreas.Zeugswetter@s-itsolutions.at>)
Ответы Re: Prereading using posix_fadvise (was Re: Commitfest patches)  (Bruce Momjian <bruce@momjian.us>)
Re: Prereading using posix_fadvise  (Gregory Stark <stark@enterprisedb.com>)
Список pgsql-hackers
Zeugswetter Andreas OSB SD wrote:
> Heikki wrote:
>> It seems that the worst case for this patch is a scan on a table that 
>> doesn't fit in shared_buffers, but is fully cached in the OS cache. In
> 
>> that case, the posix_fadvise calls would be a certain waste of time.
> 
> I think this is a misunderstanding, the fadvise is not issued to read
> the
> whole table and is not issued for table scans at all (and if it were it
> would 
> only advise for the next N pages).
> 
> So it has nothing to do with table size. The fadvise calls need to be
> (and are) 
> limited by what can be used in the near future, and not for the whole
> statement.

Right, I was sloppy. Instead of table size, what matters is the amount 
of data the scan needs to access. The point remains that if the data is 
already in OS cache, the posix_fadvise calls are a waste of time, 
regardless of how many pages ahead you advise.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


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

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: advancing snapshot's xmin
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: advancing snapshot's xmin