3 ms·
While I agree with the second tip ("Replace a live table with DROP TABLE/ALTER TABLE") for ad-hoc stuff, its big disadvantage is that it requires knowledge of t
by ilikepi 15y ago
While I agree with the second tip ("Replace a live table with DROP TABLE/ALTER TABLE") for ad-hoc stuff, its big disadvantage is that it requires knowledge of the indexes on the table. If you have one or more scripts to maintain that use this method on a particular table, and the indexes are changed in an unrelated update to your table structure, you have to make sure those changes are also reflected in your scripts.
Oracle allowed you to disable the indexes on a table (something like 'ALTER INDEX foo DISABLE'), which allowed them to become stale when data in the table was modified. You could do this right before a big import operation for example, and you could then rebuild (a different 'ALTER INDEX' syntax) them when the operation completed.
PostgreSQL doesn't appear to have an equivalent at the moment.
edit: wording
- avar 15y agoDoesn't PostgreSQL support something like: RENAME TABLE current TO current_old, current_new TO current; Which is the common pattern of atomically swapping out tables in MySQL with zero downtime.
- lentil 15y agoAlmost all DDL is transactional in PostgreSQL, so the usual equivalent to the above would be: begin; alter table current rename to current_old; alter table current_new rename to current; commit; Transaction-safe DDL is a very handy thing indeed.