Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TrErw-000534-2b for pgsql-performance@arkaria.postgresql.org; Fri, 04 Jan 2013 21:32:00 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1TrErv-0000Eu-In for pgsql-performance@arkaria.postgresql.org; Fri, 04 Jan 2013 21:31:59 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TrErt-0000C6-JN for pgsql-performance@postgresql.org; Fri, 04 Jan 2013 21:31:58 +0000 Received: from qmta03.westchester.pa.mail.comcast.net ([2001:558:fe14:43:76:96:62:32]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TrErp-0008B8-4h for pgsql-performance@postgresql.org; Fri, 04 Jan 2013 21:31:55 +0000 Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta03.westchester.pa.mail.comcast.net with comcast id juGG1k00u1ZXKqc53xXqaX; Fri, 04 Jan 2013 21:31:50 +0000 Received: from [192.168.1.176] ([69.142.185.164]) by omta21.westchester.pa.mail.comcast.net with comcast id jxXp1k00A3ZEZL53hxXpU2; Fri, 04 Jan 2013 21:31:50 +0000 Message-ID: <50E74A33.5000204@comcast.net> Date: Fri, 04 Jan 2013 16:31:31 -0500 From: AJ Weber User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Partition table in 9.0.x? References: <50E65B85.9000001@synedra.com> In-Reply-To: <50E65B85.9000001@synedra.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357335110; bh=AFtOrxgBypenevrK1zyEGKI0VuSQXHiaiPePsH0OfrM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=SBchIymOGJWQE5eF7tgmBnD6hgf6MTeXiE8yXr+udviqGiczameTmeYgsumTpGfUf eWpMl4xAqIvFCyPIQC57kSFZ6il6PKgUVmOBd56QhnHcjpfjpmgNJWg9HC830DZ6fg 0OdSsEGJxSJLMozAcJIIRNPbtRyZ7/WYRDHvFL1uheP8KSbSRiG9G4vLIZoChfCvUc /eKil7S8ym9tU2hxb7EqPnARK3Lv0g/Jv8SLl+0zgbTx8oI6V06WiULBl+4bFsHGCp Sp5dXLeKtshV0ehd63OOFX2kz4tmMy5GU6YjPX4c4tWk4u4wvOoU8ebELTKQicS3PT Gbzzz9uxbiB7A== X-Pg-Spam-Score: -2.0 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org Hi all, I have a table that has about 73mm rows in it and growing. Running 9.0.x on a server that unfortunately is a little I/O constrained. Some (maybe) pertinent settings: default_statistics_target = 50 maintenance_work_mem = 512MB constraint_exclusion = on effective_cache_size = 5GB work_mem = 18MB wal_buffers = 8MB checkpoint_segments = 32 shared_buffers = 2GB The server has 12GB RAM, 4 cores, but is shared with a big webapp running in Tomcat -- and I only have a RAID1 disk to work on. Woes me... Anyway, this table is going to continue to grow, and it's used frequently (Read and Write). From what I read, this table is a candidate to be partitioned for performance and scalability. I have tested some scripts to build the "inherits" tables with their constraints and the trigger/function to perform the work. Am I doing the right thing by partitioning this? If so, and I can afford some downtime, is dumping the table via pg_dump and then loading it back in the best way to do this? Should I run a cluster or vacuum full after all is done? Is there a major benefit if I can upgrade to 9.2.x in some way that I haven't realized? Finally, if anyone has any comments about my settings listed above that might help improve performance, I thank you in advance. -AJ -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance