Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 5538C1337B83 for ; Sat, 5 Mar 2011 05:59:26 -0400 (AST) 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 28811-06 for ; Sat, 5 Mar 2011 09:59:19 +0000 (UTC) X-Greylist: from auto-whitelisted 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 0F6021337B58 for ; Sat, 5 Mar 2011 05:59:18 -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 1PvoGc-0003Yb-Lz for pgsql-performance@postgresql.org; Sat, 05 Mar 2011 09:59:18 +0000 Message-ID: <4D720975.8050206@optrak.co.uk> Date: Sat, 05 Mar 2011 09:59:17 +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.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201103/60 X-Sequence-Number: 42739 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