Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id E0E7B6500DD for ; Sun, 20 Jul 2008 22:50:03 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 29951-08 for ; Sun, 20 Jul 2008 22:49:42 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by postgresql.org (Postfix) with ESMTP id 17A2064FFC0 for ; Sun, 20 Jul 2008 22:49:47 -0300 (ADT) Received: from newshell.sonic.net (bolt.sonic.net [208.201.242.19]) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id m6L1nhhE024409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Jul 2008 18:49:43 -0700 Received: from bolt.sonic.net (IDENT:zIBnCHyptyXKKjlAkoKZOMFXx+qNep4N@localhost.localdomain [127.0.0.1]) by newshell.sonic.net (8.13.6/8.12.1) with ESMTP id m6L1nhqq009604; Sun, 20 Jul 2008 18:49:43 -0700 Received: (from daveg@localhost) by bolt.sonic.net (8.13.6/8.12.1/Submit) id m6L1ngoV009603; Sun, 20 Jul 2008 18:49:42 -0700 Date: Sun, 20 Jul 2008 18:49:42 -0700 From: daveg To: Simon Riggs , pgsql-patches@postgresql.org Subject: Re: pg_dump additional options for performance Message-ID: <20080721014942.GC30869@sonic.net> References: <20080720030749.GA18846@tamriel.snowman.net> <1216529229.19656.835.camel@ebony.2ndQuadrant> <1216535862.19656.845.camel@ebony.2ndQuadrant> <20080720214335.GB18846@tamriel.snowman.net> <1216591180.19656.848.camel@ebony.2ndQuadrant> <20080721011829.GC18846@tamriel.snowman.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080721011829.GC18846@tamriel.snowman.net> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200807/196 X-Sequence-Number: 6890 On Sun, Jul 20, 2008 at 09:18:29PM -0400, Stephen Frost wrote: > * Simon Riggs (simon@2ndquadrant.com) wrote: > > On Sun, 2008-07-20 at 17:43 -0400, Stephen Frost wrote: > > > Even this doesn't cover everything though- it's too focused on tables > > > and data loading. Where do functions go? What about types? > > > > Yes, it is focused on tables and data loading. What about > > functions/types? No relevance here. > > I don't see how they're not relevant, it's not like they're being > excluded and in fact they show up in the pre-load output. Heck, even if > they *were* excluded, that should be made clear in the documentation > (either be an explicit include list, or saying they're excluded). > > Part of what's driving this is making sure we have a plan for future > objects and where they'll go. Perhaps it would be enough to just say > "pre-load is everything in the schema, except things which are faster > done in bulk (eg: indexes, keys)". I don't think it's right to say > pre-load is "only object definitions required to load data" when it > includes functions and ACLs though. > > Hopefully my suggestion and these comments will get us to a happy > middle-ground. One observation, indexes should be built right after the table data is loaded for each table, this way, the index build gets a hot cache for the table data instead of having to re-read it later as we do now. -dg -- David Gould daveg@sonic.net 510 536 1443 510 282 0869 If simplicity worked, the world would be overrun with insects.