OSDN Git Service

Add calcluation of bitmap storage capacity.
authorBruce Momjian <bruce@momjian.us>
Fri, 2 Dec 2005 04:28:19 +0000 (04:28 +0000)
committerBruce Momjian <bruce@momjian.us>
Fri, 2 Dec 2005 04:28:19 +0000 (04:28 +0000)
<   be cleared when a heap tuple is expired.  Another idea is to maintain
<   a bitmap of heap pages where all rows are visible to all backends,
<   and allow index lookups to reference that bitmap to avoid heap
<   lookups, perhaps the same bitmap we might add someday to determine
<   which heap pages need vacuuming.
>   be cleared when a heap tuple is expired.
>
>   Another idea is to maintain a bitmap of heap pages where all rows
>   are visible to all backends, and allow index lookups to reference
>   that bitmap to avoid heap lookups, perhaps the same bitmap we might
>   add someday to determine which heap pages need vacuuming.  Frequently
>   accessed bitmaps would have to be stored in shared memory.  One 8k
>   page of bitmaps could track 512MB of heap pages.

doc/TODO
doc/src/FAQ/TODO.html

index c3bf43a..283f99a 100644 (file)
--- a/doc/TODO
+++ b/doc/TODO
@@ -2,7 +2,7 @@
 PostgreSQL TODO List
 ====================
 Current maintainer:    Bruce Momjian (pgman@candle.pha.pa.us)
-Last updated:          Thu Dec  1 17:30:23 EST 2005
+Last updated:          Thu Dec  1 23:28:03 EST 2005
 
 The most recent version of this document can be viewed at
 http://www.postgresql.org/docs/faqs.TODO.html.
@@ -862,11 +862,14 @@ Cache Usage
   the heap.  One way to allow this is to set a bit on index tuples 
   to indicate if a tuple is currently visible to all transactions 
   when the first valid heap lookup happens.  This bit would have to 
-  be cleared when a heap tuple is expired.  Another idea is to maintain
-  a bitmap of heap pages where all rows are visible to all backends,
-  and allow index lookups to reference that bitmap to avoid heap
-  lookups, perhaps the same bitmap we might add someday to determine 
-  which heap pages need vacuuming.
+  be cleared when a heap tuple is expired.  
+
+  Another idea is to maintain a bitmap of heap pages where all rows
+  are visible to all backends, and allow index lookups to reference 
+  that bitmap to avoid heap lookups, perhaps the same bitmap we might
+  add someday to determine which heap pages need vacuuming.  Frequently
+  accessed bitmaps would have to be stored in shared memory.  One 8k
+  page of bitmaps could track 512MB of heap pages.
 
 * Consider automatic caching of queries at various levels:
 
index 7e4961e..ad86692 100644 (file)
@@ -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:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</a>)<br/>
-Last updated:           Thu Dec  1 17:30:23 EST 2005
+Last updated:           Thu Dec  1 23:28:03 EST 2005
 </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>.
@@ -781,11 +781,14 @@ first.
   the heap.  One way to allow this is to set a bit on index tuples 
   to indicate if a tuple is currently visible to all transactions 
   when the first valid heap lookup happens.  This bit would have to 
-  be cleared when a heap tuple is expired.  Another idea is to maintain
-  a bitmap of heap pages where all rows are visible to all backends,
-  and allow index lookups to reference that bitmap to avoid heap
-  lookups, perhaps the same bitmap we might add someday to determine 
-  which heap pages need vacuuming.
+  be cleared when a heap tuple is expired.  
+</p>
+<p>  Another idea is to maintain a bitmap of heap pages where all rows
+  are visible to all backends, and allow index lookups to reference 
+  that bitmap to avoid heap lookups, perhaps the same bitmap we might
+  add someday to determine which heap pages need vacuuming.  Frequently
+  accessed bitmaps would have to be stored in shared memory.  One 8k
+  page of bitmaps could track 512MB of heap pages.
 </p>
   </li><li>Consider automatic caching of queries at various levels:
   <ul>