Re: posix_fadvise v22

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: posix_fadvise v22
Дата
Msg-id 1098.1231701290@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: posix_fadvise v22  ("Robert Haas" <robertmhaas@gmail.com>)
Ответы Re: posix_fadvise v22  ("Robert Haas" <robertmhaas@gmail.com>)
Re: posix_fadvise v22  (Gregory Stark <stark@enterprisedb.com>)
Re: posix_fadvise v22  (Gregory Stark <stark@enterprisedb.com>)
Список pgsql-hackers
"Robert Haas" <robertmhaas@gmail.com> writes:
> OK, here's an update of Greg's patch with the runtime configure test
> ripped out, some minor documentation tweaks, and a few unnecessary
> whitespace diff hunks quashed.  I think this is about ready for
> committer review.

I've started to look through this, and the only part I seriously don't
like is the nbtsearch.c changes.  I've got three complaints about that:

* Doing it inside the index AMs is wrong, or at the very least forces
us to do it over for each index AM (which the patch fails to do).

* As coded, it generates prefetch bursts that are much too large and too
widely spaced to be effective, not to mention that they entirely
ignore the effective_io_concurrency control knob as well as the order
in which the pages will actually be needed.  I wonder now whether
Robert's inability to see any benefit came because he was testing
indexscans and not bitmap scans.

* It's only accidental that it's not kicking in during a bitmap
indexscan and bollixing up the much-more-carefully-written
nodeBitmapHeapscan prefetch logic.

What I intend to do over the next day or so is commit the prefetch
infrastructure and the bitmap scan prefetch logic, but I'm bouncing the
indexscan part back for rework.  I think that it should be implemented
in or near index_getnext() and pay attention to
effective_io_concurrency.
        regards, tom lane


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

Предыдущее
От: Gregory Stark
Дата:
Сообщение: Re: pgsql: Re-enable the old code in xlog.c that tried to use
Следующее
От: "Robert Haas"
Дата:
Сообщение: Re: Recovery Test Framework