Add calcluation of bitmap storage capacity.

<   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.
This commit is contained in:
Bruce Momjian 2005-12-02 04:28:19 +00:00
parent cf17131767
commit 9322a04759
2 changed files with 18 additions and 12 deletions

View File

@ -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:

View 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>