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.

--- look at a database-wide VACUUM VERBOSE.

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

Document that FOR UPDATE and LIMIT together can return fewer rows that
LIMIT specifies, and why.

logic operations during planning.  Seems cleaner to create two new Path
node types, instead --- this avoids duplication of cost-estimation code.
Also, create an enable_bitmapscan GUC parameter to control use of bitmap
plans.

<   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

allow clauseless scans.

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

>>>
>>>No, and I think it should be in the manual as an example.
>>>
>>>You will need to enter a loop that uses exception handling to detect
>>>unique_violation.
>>
>>Pursuant to an IRC discussion to which Dennis Bjorklund and
>>Christopher Kings-Lynne made most of the contributions, please find
>>enclosed an example patch demonstrating an UPSERT-like capability.
>>

David Fetter

>
> No, and I think it should be in the manual as an example.
>
> You will need to enter a loop that uses exception handling to detect
> unique_violation.

Pursuant to an IRC discussion to which Dennis Bjorklund and
Christopher Kings-Lynne made most of the contributions, please find
enclosed an example patch demonstrating an UPSERT-like capability.

David Fetter

before you are done.

indexes.  Extend the macros in include/catalog/*.h to carry the info
about hand-assigned OIDs, and adjust the genbki script and bootstrap
code to make the relations actually get those OIDs.  Remove the small
number of RelOid_pg_foo macros that we had in favor of a complete
set named like the catname.h and indexing.h macros.  Next phase will
get rid of internal use of names for looking up catalogs and indexes;
but this completes the changes forcing an initdb, so it looks like a
good place to commit.
Along the way, I made the shared relations (pg_database etc) not be
'bootstrap' relations any more, so as to reduce the number of hardwired
entries and simplify changing those relations in future.  I'm not
sure whether they ever really needed to be handled as bootstrap
relations, but it seems to work fine to not do so now.

avoid encroaching on the 'user' range of OIDs by allowing automatic
OID assignment to use values below 16k until we reach normal operation.

initdb not forced since this doesn't make any incompatible change;
however a lot of stuff will have different OIDs after your next initdb.

be supported for all datatypes.  Add CREATE AGGREGATE and pg_dump support
too.  Add specialized min/max aggregates for bpchar, instead of depending
on text's min/max, because otherwise the possible use of bpchar indexes
cannot be recognized.
initdb forced because of catalog changes.

we can put words in ulink and the URL will still be printed.

per Peter

the long-term plan for this behavior for quite some time, but it is only
possible now that DELETE has a USING clause so that the user can join
other tables in a DELETE statement without relying on this behavior.