> * Allow ORDER BY ... LIMIT 1 to select high/low value without sort or
>   index using a sequential scan for highest/lowest values
>
>   Right now, if no index exists, ORDER BY ... LIMIT 1 requires we sort
>   all values to return the high/low value.  Instead The idea is to do a
>   sequential scan to find the high/low value, thus avoiding the sort.
>

>   One possible implementation is to start sequential scans from the lowest
>   numbered buffer in the shared cache, and when reaching the end wrap
>   around to the beginning, rather than always starting sequential scans
>   at the start of the table.

<   This allows vacuum to reclaim free space without requiring
<   a sequential scan
>   This allows vacuum to target specific pages for possible free space
>   without requiring a sequential scan.

< * Research the use of larger page sizes

< * Consider parallel processing a single query
<
<   This would involve using multiple threads or processes to do optimization,
<   sorting, or execution of single query.  The major advantage of such a
<   feature would be to allow multiple CPUs to work together to process a
<   single query.
<

< * Allow ORDER BY ... LIMIT 1 to select high/low value without sort or
<   index using a sequential scan for highest/lowest values
<
<   If only one value is needed, there is no need to sort the entire
<   table. Instead a sequential scan could get the matching value.
<

> * Change WAL to use 32-bit CRC, for performance reasons

<   Solaris) might benefit from threading.
>   Solaris) might benefit from threading.  Also explore the idea of
>   a single session using multiple threads to execute a query faster.

< * Improve SMP performance on i386 machines
> * -Improve SMP performance on i386 machines

< * Optimize locale to have minimal performance impact when not used

< * Add ISo INTERVAL handling
> * Add ISO INTERVAL handling

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