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
Re: posix_fadvise v22 Re: posix_fadvise v22 |
Список | 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 по дате отправления: