Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 808C4632A2E for ; Mon, 30 Nov 2009 23:59:44 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 49120-02 for ; Tue, 1 Dec 2009 03:59:33 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outA.internet-mail-service.net (outa.internet-mail-service.net [216.240.47.224]) by mail.postgresql.org (Postfix) with ESMTP id B733A6327AB for ; Mon, 30 Nov 2009 23:59:33 -0400 (AST) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 8D150B9911 for ; Mon, 30 Nov 2009 19:59:32 -0800 (PST) X-Client-Authorized: MaGic Cook1e Received: from [192.168.2.105] (adsl-71-135-168-64.dsl.pltn13.pacbell.net [71.135.168.64]) by idiom.com (Postfix) with ESMTP id 4CDFE2D601C for ; Mon, 30 Nov 2009 19:59:32 -0800 (PST) Message-ID: <4B1494A6.8070300@obviously.com> Date: Mon, 30 Nov 2009 19:59:34 -0800 From: Bryce Nesbitt User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: pgsql-sql@postgresql.org Subject: Re: pg_restore followed by immediate VACUUM ANALYZE References: <4B1491A3.6080602@obviously.com> <19189.1259639712@sss.pgh.pa.us> In-Reply-To: <19189.1259639712@sss.pgh.pa.us> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-0.988 tagged_above=-10 required=5 tests=AWL=0.153, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457 X-Spam-Level: X-Archive-Number: 200911/87 X-Sequence-Number: 33438 Tom Lane wrote:
Does pg_restore not update the query planner statistics?
    

Correct.  Autovacuum might fix them eventually, but usually it's
worth forcing the issue once you've completed your data loading.
(This might involve multiple steps, which is why pg_restore
doesn't try to force it for you.)
Hmm.  It seems like pg_restore would already know 90% of what it needs to in this case.
Of course I'm just trying to cut down on the 4+ hour VACUUM ANALYZE.  But thanks for
the note, I'll look elsewhere for speed improvements.