From: Tom Lane <tgl@sss.pgh.pa.us>
To: Harold Falkmeyer <hfalkmeyer@gmail.com>
cc: pgsql-admin@postgresql.org
Subject: Re: Restoring From Backups
In-reply-to: 
 <CACcYriu4d8am_8nso7m94V4=8MG+_cmk1Lo=t0NHJ4m6odEknA@mail.gmail.com>
References: 
 <CACcYriu4d8am_8nso7m94V4=8MG+_cmk1Lo=t0NHJ4m6odEknA@mail.gmail.com>
Comments: In-reply-to Harold Falkmeyer <hfalkmeyer@gmail.com>
	message dated "Wed, 07 Jun 2017 12:09:26 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <14693.1496863735.1@sss.pgh.pa.us>
Date: Wed, 07 Jun 2017 15:28:55 -0400
Message-ID: <14694.1496863735@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-admin-owner@postgresql.org

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