diff options
| author | Bruce Momjian <bruce@momjian.us> | 2005-04-21 15:20:39 +0000 |
|---|---|---|
| committer | Bruce Momjian <bruce@momjian.us> | 2005-04-21 15:20:39 +0000 |
| commit | c6221db3c0f7049b804391d59aeadcfbd1f51800 (patch) | |
| tree | 1fab0cbedc7bb46dd955dd290b72093c5a2c1b98 /doc/src | |
| parent | 631e03145f823f758b12f7a3ed17409cf303f9dd (diff) | |
| download | postgresql-c6221db3c0f7049b804391d59aeadcfbd1f51800.tar.gz postgresql-c6221db3c0f7049b804391d59aeadcfbd1f51800.zip | |
Updated text for bitmaps:
< Bitmap indexes index single columns that can be combined with other bitmap
< indexes to dynamically create a composite index to match a specific query.
< Each index is a bitmap, and the bitmaps are bitwise AND'ed or OR'ed to be
< combined. They can index by tid or can be lossy requiring a scan of the
< heap page to find matching rows, or perhaps use a mixed solution where
< tids are recorded for pages with only a few matches and per-page bitmaps
< are used for more dense pages. Another idea is to use a 32-bit bitmap
< for every page and set a bit based on the item number mod(32).
> This feature allows separate indexes to be ANDed or ORed together. This
> is particularly useful for data warehousing applications that need to
> query the database in an many permutations. This feature scans an index
> and creates an in-memory bitmap, and allows that bitmap to be combined
> with other bitmap created in a similar way. The bitmap can either index
> all TIDs, or be lossy, meaning it records just page numbers and each
> page tuple has to be checked for validity in a separate pass.
Diffstat (limited to 'doc/src')
| -rw-r--r-- | doc/src/FAQ/TODO.html | 17 |
1 files changed, 8 insertions, 9 deletions
diff --git a/doc/src/FAQ/TODO.html b/doc/src/FAQ/TODO.html index 70c1e257069..725e7c312e3 100644 --- a/doc/src/FAQ/TODO.html +++ b/doc/src/FAQ/TODO.html @@ -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 Apr 21 00:09:27 EDT 2005 +Last updated: Thu Apr 21 11:20:13 EDT 2005 </p> <p>The most recent version of this document can be viewed at the PostgreSQL web<br/> site, <a href="http://www.PostgreSQL.org">http://www.PostgreSQL.org</a>. @@ -277,14 +277,13 @@ first. before accessing the heap rows. </p> </li><li>Allow non-bitmap indexes to be combined by creating bitmaps in memory -<p> Bitmap indexes index single columns that can be combined with other bitmap - indexes to dynamically create a composite index to match a specific query. - Each index is a bitmap, and the bitmaps are bitwise AND'ed or OR'ed to be - combined. They can index by tid or can be lossy requiring a scan of the - heap page to find matching rows, or perhaps use a mixed solution where - tids are recorded for pages with only a few matches and per-page bitmaps - are used for more dense pages. Another idea is to use a 32-bit bitmap - for every page and set a bit based on the item number mod(32). +<p> This feature allows separate indexes to be ANDed or ORed together. This + is particularly useful for data warehousing applications that need to + query the database in an many permutations. This feature scans an index + and creates an in-memory bitmap, and allows that bitmap to be combined + with other bitmap created in a similar way. The bitmap can either index + all TIDs, or be lossy, meaning it records just page numbers and each + page tuple has to be checked for validity in a separate pass. </p> </li><li>Allow the creation of on-disk bitmap indexes which can be quickly combined with other bitmap indexes |