X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id F28EDDA841 for ; Thu, 20 Oct 2005 07:16:37 -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 65335-09 for ; Thu, 20 Oct 2005 10:16:32 +0000 (GMT) Received: from cassarossa.samfundet.no (cassarossa.samfundet.no [129.241.93.19]) by svr1.postgresql.org (Postfix) with ESMTP id 8C97ADA146 for ; Thu, 20 Oct 2005 07:16:33 -0300 (ADT) Received: from sesse by cassarossa.samfundet.no with local (Exim 4.50) id 1ESXTO-0002zr-NU for pgsql-performance@postgresql.org; Thu, 20 Oct 2005 12:16:34 +0200 Date: Thu, 20 Oct 2005 12:16:34 +0200 From: "Steinar H. Gunderson" To: pgsql-performance@postgresql.org Subject: Re: Materializing a sequential scan Message-ID: <20051020101634.GB11055@samfundet.no> References: <20051019174544.GA32303@samfundet.no> <4248.1129783045@sss.pgh.pa.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4248.1129783045@sss.pgh.pa.us> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.012 required=5 tests=[AWL=0.012] X-Spam-Level: X-Archive-Number: 200510/281 X-Sequence-Number: 15049 On Thu, Oct 20, 2005 at 12:37:25AM -0400, Tom Lane wrote: > That mdb_gruppekobling_transitiv_tillukning function looks awfully > grotty ... how many rows does it return, and how long does it take to > run by itself? How often does its temp table get vacuumed? A quick > band-aid might be to use TRUNCATE instead of DELETE FROM to clean the > table ... but if I were you I'd try to rewrite the function entirely. It returns 752 rows, and the table is autovacuumed. If I run the queries manually, they take ~15ms in all -- for some odd reason, the function in itself varies between 40 and 500ms, though... I tried using TRUNCATE earlier, but if anything, it made the function slower (might just have been zero difference, though). I also had written the function differently (using a series of depth-first searches), but it was awfully slow even after a lot of tweaking, so it was not really worth it... /* Steinar */ -- Homepage: http://www.sesse.net/