extending questions.  Update wording of various entries.

> * -Allow non-bitmap indexes to be combined by creating bitmaps in memory

such information.  Remove MySQL mention.  Move server-side debug item to
developer's FAQ.  Update URLs.

<   Currently indexes do not have enough tuple tuple visibility
<   information to allow data to be pulled from the index without
<   also accessing the heap.  One way to allow this is to set a bit
<   to 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.
>   Currently indexes do not have enough tuple visibility information
>   to allow data to be pulled from the index without also accessing
>   the heap.  One way to allow this is to set a bit to 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.

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

< * Add tool to query pg_stat_* tables and report indexes that aren't needed
<   or tables that might need indexes

> * Add tool to query pg_stat_* tables and report indexes that aren't needed
>   or tables that might need indexes

> * Log queries where the optimizer row estimates were dramatically
>   different from the number of rows actually found (?)

> * All ability to monitor the use of temporary sort files

change content (at least not supposed to).

Magnus Hagander

Hashem Masoud

Robert Treat

Greg Sabino Mullan

Viktor Vislobokov

    <H4><A name="4.20">4.20</A>) Why do I get "missing oid" errors when
    accessing temporary tables in PL/PgSQL functions?</H4>

Merlin Moncure