diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2004-05-08 00:34:49 +0000 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2004-05-08 00:34:49 +0000 |
| commit | dd16b7aa9e1ecbe6cdd83a742f4e1655d460b38d (patch) | |
| tree | 8049deed7996450ad3e87b48f7a0d47233513953 /src/backend/catalog | |
| parent | 7c6baade7b1c3decf37cc589427adee053be74f1 (diff) | |
| download | postgresql-dd16b7aa9e1ecbe6cdd83a742f4e1655d460b38d.tar.gz | |
Get rid of cluster.c's apparatus for rebuilding a relation's indexes
in favor of using the REINDEX TABLE apparatus, which does the same thing
simpler and faster. Also, make TRUNCATE not use cluster.c at all, but
just assign a new relfilenode and REINDEX. This partially addresses
Hartmut Raschick's complaint from last December that 7.4's TRUNCATE is
an order of magnitude slower than prior releases. By getting rid of
a lot of unnecessary catalog updates, these changes buy back about a
factor of two (on my system). The remaining overhead seems associated
with creating and deleting storage files, which we may not be able to
do much about without abandoning transaction safety for TRUNCATE.
Diffstat (limited to 'src/backend/catalog')
| -rw-r--r-- | src/backend/catalog/index.c | 13 |
1 files changed, 7 insertions, 6 deletions
diff --git a/src/backend/catalog/index.c b/src/backend/catalog/index.c index 5a8d5b2267..6a994aa0cc 100644 --- a/src/backend/catalog/index.c +++ b/src/backend/catalog/index.c @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/catalog/index.c,v 1.229 2004/05/05 04:48:45 tgl Exp $ + * $PostgreSQL: pgsql/src/backend/catalog/index.c,v 1.230 2004/05/08 00:34:49 tgl Exp $ * * * INTERFACE ROUTINES @@ -1729,12 +1729,13 @@ reindex_index(Oid indexId) /* * reindex_relation - This routine is used to recreate all indexes - * of a relation (and its toast relation too, if any). + * of a relation (and optionally its toast relation too, if any). * - * Returns true if any indexes were rebuilt. + * Returns true if any indexes were rebuilt. Note that a + * CommandCounterIncrement will occur after each index rebuild. */ bool -reindex_relation(Oid relid) +reindex_relation(Oid relid, bool toast_too) { Relation rel; Oid toast_relid; @@ -1810,8 +1811,8 @@ reindex_relation(Oid relid) * If the relation has a secondary toast rel, reindex that too while we * still hold the lock on the master table. */ - if (toast_relid != InvalidOid) - result |= reindex_relation(toast_relid); + if (toast_too && OidIsValid(toast_relid)) + result |= reindex_relation(toast_relid, false); return result; } |