aboutsummaryrefslogtreecommitdiff
path: root/src/backend/commands/sequence.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2004-05-08 00:34:49 +0000
committerTom Lane <tgl@sss.pgh.pa.us>2004-05-08 00:34:49 +0000
commitdd16b7aa9e1ecbe6cdd83a742f4e1655d460b38d (patch)
tree8049deed7996450ad3e87b48f7a0d47233513953 /src/backend/commands/sequence.c
parent7c6baade7b1c3decf37cc589427adee053be74f1 (diff)
downloadpostgresql-dd16b7aa9e1ecbe6cdd83a742f4e1655d460b38d.tar.gz
postgresql-dd16b7aa9e1ecbe6cdd83a742f4e1655d460b38d.zip
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/commands/sequence.c')
0 files changed, 0 insertions, 0 deletions