Re: posix_fadvise v22

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: posix_fadvise v22
Дата
Msg-id 2083.1231706462@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: posix_fadvise v22  ("Robert Haas" <robertmhaas@gmail.com>)
Список pgsql-hackers
"Robert Haas" <robertmhaas@gmail.com> writes:
> FWIW, following your first set of commits, I extracted, cleaned up,
> and re-posted the uncommitted portion of the patch last night.  Based
> on this it doesn't sound like there's much point in continuing to do
> that, but I'm happy to do so if anyone thinks otherwise.

Probably not; I'm busy hacking on the code anyway, fixing minor issues
like its failure to do anything sane with temp tables.

A question about that part of the code: I see that PrefetchBuffer simply
does nothing if it finds the target page already in a buffer.  I wonder
whether that's sufficient, or whether we ought to do something to try
to ensure that the buffer doesn't get evicted in the near future (ie,
before we actually get to use it).

Simply advancing the usage_count seems too strong because when you
add in the upcoming ReadBuffer, we'd be advancing usage_count twice
for a single use of the page whenever it happened to get prefetched.
We could alleviate that by only advancing usage_count if it's 0, but
that seems like a band-aid not a real fix.

I also thought about setting a buffer flag bit showing that prefetch has
occurred, but then you have to worry about when/how to clear it if the
actual read never occurs.

Thoughts?
        regards, tom lane


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

Предыдущее
От: Gregory Stark
Дата:
Сообщение: Re: posix_fadvise v22
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: Review: B-Tree emulation for GIN