Harold Falkmeyer <hfalkmeyer@xxxxxxxxx> writes: > Three'ish more questions: > When restoring a table from backup (using pg_dump and pg_restore), are > there reasons, other than restoration performance, to defer index > restoration until after the COPY is complete? Mostly restoration performance: with standard btree indexes, creating an index over already-loaded data is faster than building the index incrementally. I do not think there's any benefit for GIN/GIST though; don't remember about hash. > After completing a COPY into a fresh table, is there any benefit to running > a subsequent VACUUM (given that there shouldn't be any dead tuples)? Yes, especially if you wait long enough for any transactions that were open during the COPY to go away. Then the VACUUM will mark pages all-visible, allowing index-only scans to work more efficiently. Even without that, it will set hint bits on committed tuples, removing that overhead from foreground queries. (But any other full-table scan, eg CREATE INDEX, also accomplishes the latter.) > As we understand it, an ANALYZE is necessary, regardless if we restore to a > table with preexisting indexes or one that's had indexes added after the > fact. Is this correct? Put slightly a different way, do CREATE INDEX > and/or REINDEX operations cause stats updates? Yes, you want to ANALYZE. CREATE INDEX will update the system's notion of the number of rows in the table, but not any of the more detailed stats gathered by ANALYZE (ie, what you can see in pg_stats). In most cases you'll need those stats to get decent plans for any but the most trivial queries. regards, tom lane -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
