X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 6A799528C3 for ; Thu, 23 Jun 2005 19:04:41 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 57786-10 for ; Thu, 23 Jun 2005 22:04:32 +0000 (GMT) Received: from presinet-main.presinet.com (presinet.com [209.53.156.1]) by svr1.postgresql.org (Postfix) with ESMTP id 281C45288E for ; Thu, 23 Jun 2005 19:04:31 -0300 (ADT) Received: from [10.10.1.151] (BRICK [10.10.1.151]) by presinet-main.presinet.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2658.3) id MJ7991AP; Thu, 23 Jun 2005 15:00:38 -0700 Message-ID: <42BB31F1.7000303@PresiNET.com> Date: Thu, 23 Jun 2005 15:04:33 -0700 From: Bricklen Anderson User-Agent: Debian Thunderbird 1.0.2 (X11/20050602) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jacques Caron Cc: pgsql-performance@postgresql.org Subject: Re: ETL optimization References: <42BB0F9C.2050207@PresiNET.com> <6.2.0.14.0.20050623234711.053c4d48@pop.interactivemediafactory.net> In-Reply-To: <6.2.0.14.0.20050623234711.053c4d48@pop.interactivemediafactory.net> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.015 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200506/467 X-Sequence-Number: 13104 Jacques Caron wrote: > > I have a similar situation, and the solution I use (though I haven't > really tested many different situations): > - have a trigger ON INSERT which does: > UPDATE set whatever_value=NEW.whatever_value,... WHERE > whatever_key=NEW.whatever.key AND... > IF FOUND THEN > RETURN NULL; > ELSE > RETURN NEW; > END IF; > - use COPY > > For optimal performance, a different trigger function is created for > each table, which allows the query plan of the UPDATE to be cached. > > Let us know how that works out for you and if you find a better solution! > > Jacques. > Hi Jacques, thanks for the suggestion. I've previously tested triggers under a variety of situations and there was no way that they would work under the load we currently have, and the much greater load that we will be expecting soon (~40x increase in data). I'm in the process of testing the delete scenario right now, and at first blush seems to perform fairly well. 2.5 million rows before aggregation, and 171000 after, in a little under 7 minutes. Currently testing again with about 18.5 million rows. A drawback by using the delete method is that we cannot do any of the aggregation incrementally, but so far that hasn't been a big help anyways. I still need to test the performance of concurrent querying against the destination table whilst the aggregation is occurring. -- _______________________________ This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. _______________________________