diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2011-04-19 18:51:03 -0400 | 
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2011-04-19 18:51:03 -0400 | 
| commit | ebcbc8cfe6c2d9c587ae2a25e545f09b58b666b0 (patch) | |
| tree | d203193d19a674f9dcbba0a8a5848e6ff31d9d0f /src/backend/commands/cluster.c | |
| parent | 1da9966230a30405ea5981403d4f4a9d83cb1ecb (diff) | |
Avoid changing an index's indcheckxmin horizon during REINDEX.
There can never be a need to push the indcheckxmin horizon forward, since
any HOT chains that are actually broken with respect to the index must
pre-date its original creation.  So we can just avoid changing pg_index
altogether during a REINDEX operation.
This offers a cleaner solution than my previous patch for the problem
found a few days ago that we mustn't try to update pg_index while we are
reindexing it.  System catalog indexes will always be created with
indcheckxmin = false during initdb, and with this modified code we should
never try to change their pg_index entries.  This avoids special-casing
system catalogs as the former patch did, and should provide a performance
benefit for many cases where REINDEX formerly caused an index to be
considered unusable for a short time.
Back-patch to 8.3 to cover all versions containing HOT.  Note that this
patch changes the API for index_build(), but I believe it is unlikely that
any add-on code is calling that directly.
Diffstat (limited to 'src/backend/commands/cluster.c')
| -rw-r--r-- | src/backend/commands/cluster.c | 6 | 
1 files changed, 6 insertions, 0 deletions
| diff --git a/src/backend/commands/cluster.c b/src/backend/commands/cluster.c index 61020dcbe74..153ed9a516b 100644 --- a/src/backend/commands/cluster.c +++ b/src/backend/commands/cluster.c @@ -1360,6 +1360,12 @@ finish_heap_swap(Oid OIDOldHeap, Oid OIDNewHeap,  	 * advantage to the other order anyway because this is all transactional,  	 * so no chance to reclaim disk space before commit.  We do not need a  	 * final CommandCounterIncrement() because reindex_relation does it. +	 * +	 * Note: because index_build is called via reindex_relation, it will never +	 * set indcheckxmin true for the indexes.  This is OK even though in some +	 * sense we are building new indexes rather than rebuilding existing ones, +	 * because the new heap won't contain any HOT chains at all, let alone +	 * broken ones, so it can't be necessary to set indcheckxmin.  	 */  	reindex_flags = REINDEX_SUPPRESS_INDEX_USE;  	if (check_constraints) | 
