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 commit is contained in:
parent
15f8202c20
commit
ededa6dfc8
10
doc/TODO
10
doc/TODO
@ -1,7 +1,7 @@
|
||||
PostgreSQL TODO List
|
||||
====================
|
||||
Current maintainer: Bruce Momjian (bruce@momjian.us)
|
||||
Last updated: Fri Jun 1 14:41:49 EDT 2007
|
||||
Last updated: Fri Jun 1 22:46:01 EDT 2007
|
||||
|
||||
The most recent version of this document can be viewed at
|
||||
http://www.postgresql.org/docs/faqs.TODO.html.
|
||||
@ -1090,14 +1090,6 @@ Fsync
|
||||
Cache Usage
|
||||
===========
|
||||
|
||||
* 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.
|
||||
|
||||
* Speed up COUNT(*)
|
||||
|
||||
We could use a fixed row count and a +/- count to follow MVCC
|
||||
|
@ -8,7 +8,7 @@
|
||||
<body bgcolor="#FFFFFF" text="#000000" link="#FF0000" vlink="#A00000" alink="#0000FF">
|
||||
<h1><a name="section_1">PostgreSQL TODO List</a></h1>
|
||||
<p>Current maintainer: Bruce Momjian (<a href="mailto:bruce@momjian.us">bruce@momjian.us</a>)<br/>
|
||||
Last updated: Fri Jun 1 14:41:49 EDT 2007
|
||||
Last updated: Fri Jun 1 22:46:01 EDT 2007
|
||||
</p>
|
||||
<p>The most recent version of this document can be viewed at<br/>
|
||||
<a href="http://www.postgresql.org/docs/faqs.TODO.html">http://www.postgresql.org/docs/faqs.TODO.html</a>.
|
||||
@ -971,14 +971,7 @@ first. There is also a developer's wiki at<br/>
|
||||
<h1><a name="section_14">Cache Usage</a></h1>
|
||||
|
||||
<ul>
|
||||
<li>Allow free-behind capability for large sequential scans, perhaps using
|
||||
posix_fadvise()
|
||||
<p> 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.
|
||||
</p>
|
||||
</li><li>Speed up COUNT(*)
|
||||
<li>Speed up COUNT(*)
|
||||
<p> We could use a fixed row count and a +/- count to follow MVCC
|
||||
visibility rules, or a single cached value could be used and
|
||||
invalidated if anyone modifies the table. Another idea is to
|
||||
|
Loading…
x
Reference in New Issue
Block a user