Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id F3A261337C09 for ; Wed, 4 May 2011 14:33:45 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 50622-02-3 for ; Wed, 4 May 2011 17:33:38 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-ew0-f46.google.com (mail-ew0-f46.google.com [209.85.215.46]) by mail.postgresql.org (Postfix) with ESMTP id ACBA81337BA3 for ; Wed, 4 May 2011 14:33:04 -0300 (ADT) Received: by ewy4 with SMTP id 4so425369ewy.19 for ; Wed, 04 May 2011 10:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+tbSib7Luld0NXHXomxM+5vv9AQ3ZLfbGl2YWx/YdWE=; b=DdR8qVq1crVDRHHFbDmd/vqq5AFH35gMxD8XovIEU1shUZBTW1kqymb6t+e3aT3DMY LE1ZGSmbo4nXggAESgERJZlGJqlUNEFONgHfeoMivmIsJaiyX5nPSjl6TuTMmAbpm2jo yncryTbHIHceB2wu/FCE1TckEG1s/QQ4HYzH0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=BALNXBFPS9OG5jasdVRP5NS74pVrciGDfh3LUXtkFwy5Kmb0GOzTS8rt7+Zyt9EyRh 4zivY8NRBvpDeTryyUEDrEp74xZDnvf1hhKEHUhqVXPSswDgcqgTJ3qeLEXIXcXrAcRn nWacneAlgNL6HgMmkMeer261Nh5NZnO9pkm2k= MIME-Version: 1.0 Received: by 10.213.34.12 with SMTP id j12mr758339ebd.80.1304530383277; Wed, 04 May 2011 10:33:03 -0700 (PDT) Received: by 10.213.9.81 with HTTP; Wed, 4 May 2011 10:33:03 -0700 (PDT) In-Reply-To: References: <659395.83416.qm@web39708.mail.mud.yahoo.com> Date: Wed, 4 May 2011 11:33:03 -0600 Message-ID: Subject: Re: Re: best practice for moving millions of rows to child table when setting up partitioning? From: Scott Marlowe To: Mark Stosberg Cc: pgsql-admin@postgresql.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.583 tagged_above=-10 required=5 tests=BAYES_00=-1.9, FREEMAIL_FROM=0.001, RFC_ABUSE_POST=0.001, SARE_MILLIONSOF=0.315 X-Spam-Level: X-Archive-Number: 201105/44 X-Sequence-Number: 37481 On Wed, May 4, 2011 at 11:04 AM, Mark Stosberg wrote: > It is not as findable as it could be then. Besides scanning the page, I > also searched for "child", "parent" and "partition", and none of those > words are mentioned. Neither is "inherit". Pulling out "ONLY" to have > it's own "Parameter" sub-heading also help, instead of bundling that > documentation under the "name" sub-heading. > > I suggest that at least one of the above search terms be added to better > relate the documentation to the partitioning documentation. Agreed. > Further, since TRUNCATE permanently and instantly deletes mass amounts > of data, I would hope that it would provide "safety" by default, but > only truncating one table unless I specify otherwise. Keep in mind you're using postgres, the only thing you can't wrap in a transaction is create / drop tablespace or database. So you can test your truncate within a transaction to be sure it's doing what you want.