< 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.
< failure.
> failure. This could be triggered by a user command or a timer.
< * Force archiving of partially-full WAL files when pg_stop_backup() is
< called or the server is stopped
> * Automatically force archiving of partially-filled WAL files when
> pg_stop_backup() is called or the server is stopped
< * Add ANSI INTERVAL handling
> * Add ISo INTERVAL handling
< o Interpret syntax that isn't uniquely ANSI or PG, like '1:30' or
< '1' as ANSI syntax, e.g. interpret '1:30' MINUTE TO SECOND as
> o Interpret syntax that isn't uniquely ISO or PG, like '1:30' or
> '1' as ISO syntax, e.g. interpret '1:30' MINUTE TO SECOND as
649c649
< * Add pre-parsing phase that converts non-ANSI syntax to supported
> * Add pre-parsing phase that converts non-ISO syntax to supported
< o Process mixed ANSI/PG syntax, and round value to requested
< precision or generate an error
< o Interpret INTERVAL '1 year' MONTH as CAST (INTERVAL '1 year' AS
< INTERVAL MONTH), and this should return '12 months'
194a191,194
> o Interpret INTERVAL '1 year' MONTH as CAST (INTERVAL '1 year' AS
> INTERVAL MONTH), and this should return '12 months'
> o Round or truncate values to the requested precision, e.g.
> INTERVAL '11 months' AS YEAR should return one or zero
< o Add support for day-time syntax, INTERVAL '1 2:03:04'
> o Add support for day-time syntax, INTERVAL '1 2:03:04'
192c192,194
< o Interpret INTERVAL '1:30' MINUTE TO SECOND as '1 minute 30 seconds'
> o Interpret syntax that isn't uniquely ANSI or PG, like '1:30' or
> '1' as ANSI syntax, e.g. interpret '1:30' MINUTE TO SECOND as
> '1 minute 30 seconds'
< * Add support for ANSI time INTERVAL syntax, INTERVAL '1 2:03:04' DAY TO SECOND
< * Add support for ANSI date INTERVAL syntax, INTERVAL '20-6' YEAR TO MONTH
< * Process mixed ANSI/PG INTERVAL syntax, and round value to requested precision
<
< Interpret INTERVAL '1 year' MONTH as CAST (INTERVAL '1 year' AS INTERVAL
< MONTH), and this should return '12 months'
<
< * Interpret INTERVAL '1:30' MINUTE TO SECOND as '1 minute 30 seconds'
> * Add ANSI INTERVAL handling
> o Add support for day-time syntax, INTERVAL '1 2:03:04'
> DAY TO SECOND
> o Add support for year-month syntax, INTERVAL '50-6' YEAR TO MONTH
> o Process mixed ANSI/PG syntax, and round value to requested
> precision or generate an error
> o Interpret INTERVAL '1 year' MONTH as CAST (INTERVAL '1 year' AS
> INTERVAL MONTH), and this should return '12 months'
> o Interpret INTERVAL '1:30' MINUTE TO SECOND as '1 minute 30 seconds'
> o Support precision, CREATE TABLE foo (a INTERVAL MONTH(3))
< * Add support for ANSI date INTERVAL syntax, INTERVAL '9-3' YEAR TO MONTH
> * Add support for ANSI date INTERVAL syntax, INTERVAL '20-6' YEAR TO MONTH
< * Add support for ANSI date INTERVAL syntax, INTERVAL '1-2' YEAR TO MONTH
> * Add support for ANSI date INTERVAL syntax, INTERVAL '9-3' YEAR TO MONTH
> * Add support for ANSI time INTERVAL syntax, INTERVAL '1 2:03:04' DAY TO SECOND
> * Add support for ANSI date INTERVAL syntax, INTERVAL '1-2' YEAR TO MONTH
> * Process mixed ANSI/PG INTERVAL syntax, and round value to requested precision
184a188,189
> Interpret INTERVAL '1 year' MONTH as CAST (INTERVAL '1 year' AS INTERVAL
> MONTH), and this should return '12 months'
>
> * Support table partitioning that allows a single table to be stored
> in subtables that are partitioned based on the primary key or a WHERE
> clause
< SQL-spec compliant, so allow such handling to be disabled.
> SQL-spec compliant, so allow such handling to be disabled. However,
> disabling backslashes could break many third-party applications and tools.
< o Disallow encodings like UTF8 which PostgreSQL supports
< but the operating system does not (already disallowed by
< pginstaller)
> o Add support for Unicode
< To fix UTF8, the data needs to be converted to UTF16 and then
< the Win32 wcscoll() can be used, and perhaps other functions
> To fix this, the data needs to be converted to/from UTF16/UTF8
> so the Win32 wcscoll() can be used, and perhaps other functions
< locales but provides no ordering.
<
> locales but provides no ordering or character set classes.
< * Allow server configuration parameters to be remotely modified
> * Allow pg_hba.conf settings to be controlled via SQL
>
> This would require a new global table that is dumped to flat file for
> use by the postmaster. We do a similar thing for pg_shadow currently.
>
< * Consider use of open/fcntl(O_DIRECT) to minimize OS caching
> * Consider use of open/fcntl(O_DIRECT) to minimize OS caching,
> especially for WAL writes
the item:
< o Automatic failover
<
< The proper solution to this will probably the use of a master/slave
< replication solution like Sloney and a connection pooling tool like
< pgpool.
<
< all temporary tables, removal of any NOTIFYs, etc. This could be used
< for connection pooling. We could also change RESET ALL to have this
< functionality.
> all temporary tables, removal of any NOTIFYs, cursors, prepared
> queries(?), currval()s, etc. This could be used for connection pooling.
> We could also change RESET ALL to have this functionality.
< BY col {DESC} LIMIT 1. Completing this item involves making this
> BY col {DESC} LIMIT 1. Completing this item involves doing this
< invalidated if anyone modifies the table.
<
> invalidated if anyone modifies the table. Another idea is to
> get a count directly from a unique index, but for this to be
> faster than a sequential scan it must avoid access to the heap
> to obtain tuple visibility information.
>
> * Allow data to be pulled directly from indexes
>
> 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.
>
< * Allow building with directories containing spaces
> * Allow building in directories containing spaces
< There are two capabilities here, first the ability to build from a
< source directory that contains spaces, and second the ability to install
< into a directory that contains spaces. The first is probably not
< possible because 'gmake' and other compiler tools do not fully support
< spaces in path names. The second is possible with proper quoting in
< the makefiles. Because PostgreSQL supports relocatable installs, it
< is possible to install into a directory that doesn't contain spaces and
< then copy the install to a directory with spaces.
> This is probably not possible because 'gmake' and other compiler tools
> do not fully support quoting of paths with spaces.
>
> * Allow installing to directories containing spaces
>
> This is possible if proper quoting is added to the makefiles for the
> install targets. Because PostgreSQL supports relocatable installs, it
> is already possible to install into a directory that doesn't contain
> spaces and then copy the install to a directory with spaces.
> There are two capabilities here, first the ability to build from a
> source directory that contains spaces, and second the ability to install
> into a directory that contains spaces. The first is probably not
> possible because 'gmake' and other compiler tools do not fully support
> spaces in path names. The second is possible with proper quoting in
> the makefiles. Because PostgreSQL supports relocatable installs, it
> is possible to install into a directory that doesn't contain spaces and
> then copy the install to a directory with spaces.
< o Disallow encodings like UTF8 which which PostgreSQL supports
> o Disallow encodings like UTF8 which PostgreSQL supports
914a915,917
>
> To fix UTF8, the data needs to be converted to UTF16 and then
> the Win32 strcoll() can be used.
> * Improve the background writer
>
> Allow the background writer to more efficiently write dirty buffers
> from the end of the LRU cache and use a clock sweep algorithm to
> write other dirty buffers to reduced checkpoint I/O
>
> * Allow the size of the buffer cache used by temporary objects to be
> specified as a GUC variable
>
> Larger local buffer cache sizes requires more efficient handling of
> local cache lookups.
< * Make log_min_duration_statement output when the duration is reached rather
< than when the statement completes
<
< This prints long queries while they are running, making trouble shooting
< easier. Also, it eliminates the need for log_statement because it
< would now be the same as a log_min_duration_statement of zero.
> * Make log_min_duration_statement output when the duration is reached rather
> than when the statement completes
>
> This prints long queries while they are running, making trouble shooting
> easier. Also, it eliminates the need for log_statement because it
> would now be the same as a log_min_duration_statement of zero.
9c5
< Last updated: Mon Nov 29 23:33:09 EST 2004
> Last updated: Tue Nov 30 00:03:37 EST 2004
13a10,16
> #A hyphen, "-", marks changes that will appear in the upcoming 8.1 release.#
>
> Bracketed items, "[]", have more detail.
>
> This list contains all known PostgreSQL bugs and feature requests. If
> you would like to work on an item, please read the developer's FAQ
> first.
