-
Notifications
You must be signed in to change notification settings - Fork 7
Home
The pg_reorg developers are slowly moving the project from its old home on pgfoundry to github. The current stable release of pg_reorg is 1.1.7. The project mailing list is hosted on pgfoundry at reorg-general. Please report bugs on the github issue tracker.
Official documentation page: pg_reorg, though this wiki page may serve as an unofficial documentation point.
Please help keep this wiki page up-to-date!
pg_reorg is handy when you have a large table which has become bloated (see Show database bloat for a useful bloat-detection query). If you are able to hold an AccessExclusive lock on the table for an extended period, you have it easy: just use CLUSTER or VACUUM FULL. However, if your table is busy being accessed by queries which can't wait hours while a CLUSTER or VACUUM FULL completes, you need a solution which will de-bloat your table and indexes while allowing concurrent reads and writes of the table. pg_reorg allows you to do precisely this. See also depesz's summary.
A few features have been added to cvs, git master or another git branch, and are not yet in a stable release. TODO: break this list out into items to be fixed in REL1_1, items committed to git master, and items in other git branches.
- Bundle pg_reorg as an extension, so CREATE EXTENSION can be used
- Make pg_reorg available on pgxn
- Use ALTER TABLE ... ENABLE ALWAYS so pg_reorg can operate on a Slony slave node: http://pgfoundry.org/pipermail/reorg-general/2012-October/000094.html
- Print status message while waiting on table lock: http://pgfoundry.org/pipermail/reorg-general/2012-September/000069.html
- Column name quoting: http://pgfoundry.org/pipermail/reorg-general/2012-September/000071.html
- Trigger to prevent TRUNCATE on target table.
- Problem using pg_reorg on a newly-promoted streaming replication slave: Bug #1011203, PG Bug
- It is generally unsafe to perform DDL on your table while it is being reorg'ed, except for VACUUM or ANALYZE. Although the primary benefit of pg_reorg is that it does not hold a high-level lock on the target table while it is being reorg'ed, this also leaves us with no hard and fast way to prevent unsafe DDL. Perhaps we could add in some sanity checks of pg_class, pg_tablespace, etc. before and after the reorg finishes, and throw an error if any unexpected changes in the table attributes are detected.
- pg_reorg chokes when an invalid index is left behind e.g. by CREATE INDEX CONCURRENTLY: http://pgfoundry.org/pipermail/reorg-general/2012-October/000101.html
- Concurrent index builds using multiple connections.