< * Use bitmaps to combine existing indexes [performance]
> * Allow the creation of bitmap indexes which can be quickly combined
> with other bitmap indexes
255,257c256,266
< Bitmap indexes allow single indexed columns to be combined to
< dynamically create a composite index to match a specific query. Each
< index is a bitmap, and the bitmaps are AND'ed or OR'ed to be combined.
> 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. Such indexes could be more compact if there are few unique
> value. Also, perhaps they can be lossy requiring a scan of the heap page
> to find matching rows.
>
> * Allow non-bitmap indexes to be combined
>
> Do lookups on non-bitmap indexes and create bitmaps in memory that can be
> combined with other indexes.
< This perhaps should use a round-robin allocation system where several
< tablespaces are used in a cycle. The cycle pointer should be global.
> It could start with a random tablespace from a supplied list and cycle
> through the list.
< * Add a GUC variable to control the tablespace for temporary objects
> * Add a GUC variable to control the tablespace for temporary objects and
> sort files
>
> This perhaps should use a round-robin allocation system where several
> tablespaces are used in a cycle. The cycle pointer should be global.
>
Use this new function in psql. Implement query cancellation in psql for
Windows. Code by Magnus Hagander, documentation and minor editorialization
by Tom Lane.
of HeapTupleSatisfiesItself() to trigger a hint-bit update on the tuple:
if the row was updated or deleted by a subtransaction of my own transaction
that was later rolled back. This cannot occur in pre-8.0 of course, so
the hint-bit patch applied a couple weeks ago is OK for existing releases.
But for 8.0 it seems we had better fix things so that RI_FKey_check can
pass the correct buffer number to HeapTupleSatisfiesItself. Accordingly,
add fields to the TriggerData struct to carry the buffer ID(s) for the
old and new tuple(s). There are other possible solutions but this one
seems cleanest; it will allow other AFTER-trigger functions to safely
do tqual.c calls if they want to. Put new fields at end of struct so
that there is no API breakage.
at the top level of the column's old default expression before adding
an implicit coercion to the new column type. This seems to satisfy the
principle of least surprise, as per discussion of bug #1290.
NO ACTION check is deferrable. This seems to be a closer approximation
to what the SQL spec says than what we were doing before, and it prevents
some anomalous behaviors that are possible now that triggers can fire
during the execution of PL functions.
Stephan Szabo.
< The proper solution to this will probably the use of a master/slave
< replication solution like Sloney and a connection pooling tool like
< pgpool.
> The proper solution to this will probably the use of a master/slave
> replication solution like Sloney and a connection pooling tool like
> pgpool.
114,116c114,116
< You can use any of the master/slave replication servers to use a
< standby server for data warehousing. To allow read/write queries to
< multiple servers, you need multi-master replication like pgcluster.
> You can use any of the master/slave replication servers to use a
> standby server for data warehousing. To allow read/write queries to
> multiple servers, you need multi-master replication like pgcluster.
166,167c166,167
< Currently large objects entries do not have owners. Permissions can
< only be set at the pg_largeobject table level.
> Currently large objects entries do not have owners. Permissions can
> only be set at the pg_largeobject table level.
173c173
< This requires the TOAST column to be stored EXTERNAL.
> This requires the TOAST column to be stored EXTERNAL.
359,360c359,360
< One complexity is whether moving a schema should move all existing
< schema objects or just define the location for future object creation.
> One complexity is whether moving a schema should move all existing
> schema objects or just define the location for future object creation.
364,365c364,365
< Currently non-global system tables must be in the default database
< schema. Global system tables can never be moved.
> Currently non-global system tables must be in the default database
> schema. Global system tables can never be moved.
371,375c371,375
< This might require some background daemon to maintain clustering
< during periods of low usage. It might also require tables to be only
< paritally filled for easier reorganization. Another idea would
< be to create a merged heap/index data file so an index lookup would
< automatically access the heap data too.
> This might require some background daemon to maintain clustering
> during periods of low usage. It might also require tables to be only
> paritally filled for easier reorganization. Another idea would
> be to create a merged heap/index data file so an index lookup would
> automatically access the heap data too.
379,380c379,380
< To do this, determine the ideal cluster index for each system
< table and set the cluster setting during initdb.
> To do this, determine the ideal cluster index for each system
> table and set the cluster setting during initdb.
385,386c385,386
< This requires the use of a savepoint before each COPY line is
< processed, with ROLLBACK on COPY failure.
> This requires the use of a savepoint before each COPY line is
> processed, with ROLLBACK on COPY failure.
395,398c395,398
< This requires using the row ctid to map cursor rows back to the
< original heap row. This become more complicated if WITH HOLD cursors
< are to be supported because WITH HOLD cursors have a copy of the row
< and no FOR UPDATE lock.
> This requires using the row ctid to map cursor rows back to the
> original heap row. This become more complicated if WITH HOLD cursors
> are to be supported because WITH HOLD cursors have a copy of the row
> and no FOR UPDATE lock.
405,406c405,406
< Because WITH HOLD cursors exist outside transactions, this allows
< them to be listed so they can be closed.
> Because WITH HOLD cursors exist outside transactions, this allows
> them to be listed so they can be closed.
413,415c413,415
< This is useful for returning the auto-generated key for an INSERT.
< One complication is how to handle rules that run as part of
< the insert.
> This is useful for returning the auto-generated key for an INSERT.
> One complication is how to handle rules that run as part of
> the insert.
422c422
< This is basically the same as SET search_path.
> This is basically the same as SET search_path.
426,427c426,427
< This requires a checking function to be called after the server
< configuration file is read.
> This requires a checking function to be called after the server
> configuration file is read.
432c432
< Currently only constants are supported.
> Currently only constants are supported.
438,439c438,439
< This requires the cached PL/PgSQL byte code to be invalidated when
< an object referenced in the function is changed.
> This requires the cached PL/PgSQL byte code to be invalidated when
> an object referenced in the function is changed.
512,513c512,513
< Document differences between ecpg and the SQL standard and
< information about the Informix-compatibility module.
> Document differences between ecpg and the SQL standard and
> information about the Informix-compatibility module.
* Allow a database in tablespace t1 with tables created in tablespace t2
to be used as a template for a new database created with default
tablespace t2
All objects in the default database tablespace must have default tablespace
specifications. This is because new databases are created by copying
directories. If you mix default tablespace tables and tablespace-specified
tables in the same directory, creating a new database from such a mixed
directory would create a new database with tables that had incorrect
explicit tablespaces. To fix this would require modifying pg_class in the
newly copied database, which we don't currently do.
>
> * Allow a database in tablespace t1 with tables created in tablespace t2
> to be used as a template for a new database created with default
> tablespace t2
>
> All objects in the default database tablespace must have default tablespace
> specifications. This is because new databases are created by copying
> directories. If you mix default tablespace tables and tablespace-specified
> tables in the same directory, creating a new database from such a mixed
> directory would create a new database with tables that had incorrect
> explicit tablespaces. To fix this would require modifying pg_class in the
> newly copied database, which we don't currently do.
This does not disable the bgwriter process: it still has to wake up often
enough to collect fsync requests from backends in a timely fashion. But
it responds to the recent gripe about not being able to prevent the disk
from being spun up constantly.
