Received: from localhost (maia-5.hub.org [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id 147E89FB273 for ; Wed, 10 Jan 2007 16:25:00 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-new, port 10024) with ESMTP id 59458-03 for ; Wed, 10 Jan 2007 16:24:44 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from noel.decibel.org (noel.decibel.org [67.100.216.10]) by postgresql.org (Postfix) with ESMTP id 74A1B9FB25C for ; Wed, 10 Jan 2007 16:24:46 -0400 (AST) Received: by noel.decibel.org (Postfix, from userid 1001) id 646EE56442; Wed, 10 Jan 2007 14:24:45 -0600 (CST) Received: (hashcash-sendmail, from uid 1001); Wed, 10 Jan 2007 14:24:42 -0600 Date: Wed, 10 Jan 2007 14:24:42 -0600 From: "Jim C. Nasby" To: Steven Flatt Cc: Colin Taylor , pgsql-performance@postgresql.org Subject: Re: table partioning performance Message-ID: <20070110202442.GV12217@nasby.net> References: <84d3067d0701062037k3229c9ddjbde73b1fd79ee209@mail.gmail.com> <357fa7590701081202p726c049ej61390dd1816d1369@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <357fa7590701081202p726c049ej61390dd1816d1369@mail.gmail.com> X-Operating-System: FreeBSD 6.1-RELEASE-p10 amd64 X-Distributed: Join the Effort! http://www.distributed.net User-Agent: Mutt/1.5.13 (2006-08-11) X-Hashcash: 1:20:070110:steven.flatt@gmail.com::AH14gRdJnKv0dq6E:000000000000000 0000000000000000000000000NN3 X-Hashcash: 1:20:070110:colin.taylor@gmail.com::q/PEKi/FVRcfxVGp:000000000000000 0000000000000000000000001hoD X-Hashcash: 1:20:070110:pgsql-performance@postgresql.org::00vrLutNUWpWHL6U:00000 0000000000000000000000002lto X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200701/145 X-Sequence-Number: 22746 On Mon, Jan 08, 2007 at 03:02:24PM -0500, Steven Flatt wrote: > We use partitioned tables extensively and we have observed linear > performance degradation on inserts as the number of rules on the master > table grows (i.e. number of rules = number of partitions). We had to come > up with a solution that didn't have a rule per partition on the master > table. Just wondering if you are observing the same thing. Except for the simplest partitioning cases, you'll be much better off using a trigger on the parent table to direct inserts/updates/deletes to the children. As a bonus, using a trigger makes it a lot more realistic to deal with an update moving data between partitions. -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)