提交 9322a047 编写于 作者: B Bruce Momjian

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.
上级 cf171317
......@@ -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:
......
......@@ -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>
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册