Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 5644C1337B92 for ; Sat, 5 Mar 2011 07:01:52 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 54681-01 for ; Sat, 5 Mar 2011 11:01:44 +0000 (UTC) X-Greylist: delayed 01:03:52.567189 by SQLgrey-1.7.6 Received: from mail.optrak.co.uk (mail.optrak.co.uk [217.206.42.18]) by mail.postgresql.org (Postfix) with ESMTP id AF8A11337B3E for ; Sat, 5 Mar 2011 07:01:43 -0400 (AST) Received: from cpc3-ware5-2-0-cust73.9-1.cable.virginmedia.com ([82.11.127.74] helo=[192.168.0.103]) by mail.optrak.co.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71) (envelope-from ) id 1PvoFB-0003XZ-T5 for pgsql-performance@postgresql.org; Sat, 05 Mar 2011 09:57:49 +0000 Message-ID: <4D72091C.8030809@optrak.com> Date: Sat, 05 Mar 2011 09:57:48 +0000 From: Mark Thornton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.14) Gecko/20110221 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: Table partitioning References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9 X-Spam-Level: X-Archive-Number: 201103/64 X-Sequence-Number: 42743 On 05/03/2011 09:37, Tobias Brox wrote: > Sorry for not responding directly to your question and for changing > the subject ... ;-) > > On 4 March 2011 18:18, Landreville wrote: >> That is partitioned into about 3000 tables by the switchport_id (FK to >> a lookup table), each table has about 30 000 rows currently (a row is >> inserted every 5 minutes into each table). > Does such partitioning really make sense? My impression is that the > biggest benefit with table partitioning is to keep old "inactive" data > out of the caches. If so, then it doesn't seem to make much sense to > split a table into 3000 active partitions ... unless, maybe, almost > all queries goes towards a specific partitioning. If your partitions a loosely time based and you don't want to discard old data, then surely the number of partitions will grow without limit. You could have partitions for say the last 12 months plus a single partition for 'ancient history', but then you have to transfer the content of the oldest month to ancient each month and change the constraint on 'ancient'. Mark