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

ExprContexts will be freed anyway when FreeExecutorState() is reached,
and letting that routine do the work is more efficient because it will
automatically free the ExprContexts in reverse creation order.  The
existing coding was effectively freeing them in exactly the worst
possible order, resulting in O(N^2) behavior inside list_delete_ptr,
which becomes highly visible in cases with a few thousand plan nodes.

ExecFreeExprContext is now effectively a no-op and could be removed,
but I left it in place in case we ever want to put it back to use.

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

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

statement.

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.

suggestion from Qingqing Zhou.

Per discussion with Paul Edwards.

protocol output routines.  Mea culpa :-(.  Per report from Kris Jurka.

c_expr.  Perhaps the restriction was once needed to avoid bison errors,
but it seems to work just fine now --- and even generates a slightly
smaller state machine.  This change allows examples like
SELECT '13:45'::timetz AT TIME ZONE '-07:00'::interval;
to work without parentheses around the right-hand input.

aren't 1-D, so give an error message instead of failing.  Per report
from Ron Mayer.

code in prepqual.c had a small drawback: the flatten_andors code was
able to cope with deeply nested AND/OR structures (like 10000 ORs in
a row), whereas eval_const_expressions tends to recurse until it
overruns the stack.  Revise eval_const_expressions so that it doesn't
choke on deeply nested ANDs or ORs.

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

make some estimate of which available indexes to AND together, rather
than blindly taking 'em all.  This could probably stand further
improvement, but it seems to do OK in simple tests.

BitmapOr nodes.

but the code is basically working.  Along the way, rewrite the entire
approach to processing OR index conditions, and make it work in join
cases for the first time ever.  orindxpath.c is now basically obsolete,
but I left it in for the time being to allow easy comparison testing
against the old implementation.

<   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