Received: from localhost (unknown [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id 4C2822E0083 for ; Thu, 29 Nov 2007 12:17:41 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024) with ESMTP id 92852-05 for ; Thu, 29 Nov 2007 12:17:36 -0400 (AST) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id EC57B2E0047 for ; Thu, 29 Nov 2007 12:17:35 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.1/8.14.1) with ESMTP id lATGHP3G014456; Thu, 29 Nov 2007 11:17:25 -0500 (EST) To: "Joshua D. Drake" cc: Michael Paesold , NikhilS , David Fetter , "Jonah H. Harris" , PostgreSQL Docs , PostgreSQL Patches Subject: Re: [PATCHES] Partition: use triggers instead of rules In-reply-to: <474EE25E.3080304@commandprompt.com> References: <20071128202615.GG24146@fetter.org> <21686.1196283184@sss.pgh.pa.us> <36e682920711281858x9a37039sa104036bf025de41@mail.gmail.com> <20071129031702.GU24146@fetter.org> <2854.1196315753@sss.pgh.pa.us> <20071128224154.06f950c9@commandprompt.com> <474EDAE2.3010705@gmx.at> <474EE25E.3080304@commandprompt.com> Comments: In-reply-to "Joshua D. Drake" message dated "Thu, 29 Nov 2007 08:01:34 -0800" Date: Thu, 29 Nov 2007 11:17:25 -0500 Message-ID: <14455.1196353045@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200711/125 X-Sequence-Number: 4658 "Joshua D. Drake" writes: > Rules are extremely slow in comparisons and not anywhere near as > flexible. As I said up post yesterday... they work well in the basic > partitioning configuration but anything else they are extremely deficient. I think that the above claim is exceedingly narrow-minded. A trigger will probably beat a rule for inserts/updates involving a small number of rows. For large numbers of rows, like an INSERT/SELECT from another large table, the rule is likely to win, because its overhead is paid once per query not once per row. Also, if you implement the trigger with an EXECUTE (forcing a planning cycle) intead of hard-coded commands, the speed advantage becomes even more dubious. regards, tom lane