pg.ddx.io pgsql-admin@postgresql.org mailing list archivehelp / color / mirror / Atom feed
Restoring From Backups 2+ messages / 2 participants [nested] [flat]
* Restoring From Backups @ 2017-06-07 19:09 Harold Falkmeyer <hfalkmeyer@gmail.com> 2017-06-07 19:28 ` Re: Restoring From Backups Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 1 reply; 2+ messages in thread From: Harold Falkmeyer @ 2017-06-07 19:09 UTC (permalink / raw) To: pgsql-admin Greetings, 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? 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)? 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? Thank you in advance, Harold Falkmeyer ^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Restoring From Backups 2017-06-07 19:09 Restoring From Backups Harold Falkmeyer <hfalkmeyer@gmail.com> @ 2017-06-07 19:28 ` Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 2+ messages in thread From: Tom Lane @ 2017-06-07 19:28 UTC (permalink / raw) To: Harold Falkmeyer <hfalkmeyer@gmail.com>; +Cc: pgsql-admin Harold Falkmeyer <hfalkmeyer@gmail.com> 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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2017-06-07 19:28 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2017-06-07 19:09 Restoring From Backups Harold Falkmeyer <hfalkmeyer@gmail.com> 2017-06-07 19:28 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox