pgsql: TODO item not needed anymore now that the buffer cache is
Log Message:
-----------
TODO item not needed anymore now that the buffer cache is
scan-resistant:
<
< * Allow free-behind capability for large sequential scans, perhaps using
< posix_fadvise()
<
< Posix_fadvise() can control both sequential/random file caching and
< free-behind behavior, but it is unclear how the setting affects other
< backends that also have the file open, and the feature is not supported
< on all operating systems.
Modified Files:
--------------
pgsql/doc:
TODO (r1.2197 -> r1.2198)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/TODO.diff?r1=1.2197&r2=1.2198)
pgsql/doc/src/FAQ:
TODO.html (r1.698 -> r1.699)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/FAQ/TODO.html.diff?r1=1.698&r2=1.699)
On Fri, 1 Jun 2007, Bruce Momjian wrote:
Log Message:
-----------
TODO item not needed anymore now that the buffer cache is
scan-resistant:<
< * Allow free-behind capability for large sequential scans, perhaps using
< posix_fadvise()
<
< Posix_fadvise() can control both sequential/random file caching and
< free-behind behavior, but it is unclear how the setting affects other
< backends that also have the file open, and the feature is not supported
< on all operating systems.
This todo item is about telling the OS cache that we don't want these
buffers kept around, not about pg's own buffer cache. So I think it's
still valid.
Kris Jurka
Kris Jurka wrote:
On Fri, 1 Jun 2007, Bruce Momjian wrote:
Log Message:
-----------
TODO item not needed anymore now that the buffer cache is
scan-resistant:<
< * Allow free-behind capability for large sequential scans, perhaps using
< posix_fadvise()
<
< Posix_fadvise() can control both sequential/random file caching and
< free-behind behavior, but it is unclear how the setting affects other
< backends that also have the file open, and the feature is not supported
< on all operating systems.This todo item is about telling the OS cache that we don't want these
buffers kept around, not about pg's own buffer cache. So I think it's
still valid.
Agreed, re-added, and clarified it is for the kernel cache:
* Allow free-behind capability for large sequential scans to avoid
kernel cache spoiling
Posix_fadvise() can control both sequential/random file caching and
free-behind behavior, but it is unclear how the setting affects other
backends that also have the file open, and the feature is not supported
on all operating systems.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +