Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 03513B5DBF0 for ; Fri, 8 Jul 2011 15:51:13 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 57665-01 for ; Fri, 8 Jul 2011 18:51:06 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from eastrmfepo201.cox.net (eastrmfepo201.cox.net [68.230.241.216]) by mail.postgresql.org (Postfix) with ESMTP id 46F8FB5DBE9 for ; Fri, 8 Jul 2011 15:51:00 -0300 (ADT) Received: from eastrmimpo03.cox.net ([68.1.16.126]) by eastrmfepo201.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20110708185051.WKWM32549.eastrmfepo201.cox.net@eastrmimpo03.cox.net>; Fri, 8 Jul 2011 14:50:51 -0400 Received: from slacker.ja10629.home ([68.106.109.147]) by eastrmimpo03.cox.net with bizsmtp id 5Wqo1h00B3Ar1Vg02WqorH; Fri, 08 Jul 2011 14:50:50 -0400 X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020206.4E17518A.01D6,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=1.1 cv=C3qvW7ijbZHIuWG+8RIdPMgD+cQ1zedB2RPq15YaT1I= c=1 sm=1 a=z1TLwsU0kBEA:10 a=PjkiJtDTOQ4A:10 a=ZcFhQy0-F_sA:10 a=kj9zAlcOel0A:10 a=sXZhTwfwSKhiTs9RzZXpNQ==:17 a=hdQED6aibhpPqC4sWUMA:9 a=ZxlQz2zIT0eTe9GG1SQA:7 a=CjuIK1q_8ugA:10 a=0csefQST07QOEijt:21 a=y97-T3JoHL7Gi7gF:21 a=sXZhTwfwSKhiTs9RzZXpNQ==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Received: from wcuddy by slacker.ja10629.home with local (Exim 4.72) (envelope-from ) id 1QfG8W-0005cV-0M; Fri, 08 Jul 2011 14:50:48 -0400 Date: Fri, 8 Jul 2011 14:50:47 -0400 From: lists-pgsql@useunix.net To: pgsql-sql@postgresql.org Cc: viktor.bojovic@gmail.com Subject: Re: overload Message-ID: <20110708185047.GL13621@slacker.ja10629.home> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-5 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201107/25 X-Sequence-Number: 35595 I'm have the same situation with large tables. Take a look at using a cursor to fetch several thousand rows at a time. I presume what's happening is that perl is attempting to create a massive list/array in memory. If you use a cursor the list should only contain X number of rows where X in the number specified at each fetch execution. You'll need to define the cursor inside a transaction block. - begin transaction - define the cursor - fetch rows from cursor - while row count from previous step > 0, execute previous step - terminate transaction Or you could use plpgsql instead of plperl, FOR loops over result sets in plpgsql implicitly use cursors... it's just a little less code. Hope that helps, Wayne On Tue, Jul 05, 2011 at 10:29:03PM +0200, Viktor Bojovi?? wrote: > Hi, > while reading 20GB table through PL/PERL function , it constantly grows in > RAM. > I wanted to ask you which is the best way to read table inside that > function without such memory consumption. > Thanks in advance > > Code is here: > > CREATE FUNCTION pattern_counter("patLength" integer) > RETURNS varchar AS > $BODY$ > my $rv = spi_exec_query("select sequence from entry"); > my $rowCount = $rv->{processed}; > my $patLen = $_[0]; > my $patt = ''; > my %patterns=(); > foreach my $rn (0 .. $rowCount -1){ > my $row = $rv->{rows}[$rn]; > my $seq = $row->{sequence}; > for (my $x = 1;$x<=length($seq) - $patLen;$x++){ > $patt=substr($seq,$x,$patLen); > if (! defined $patterns{$patt}) { > $patterns{$patt}=1; > }else{ > $patterns{$patt}++; > } > } > } > foreach $patt (keys %patterns){ > my $sql="insert into patterns values('".$patt."',".$patterns{$patt}.")"; > spi_exec_query($sql); > } > return ''; > $BODY$ > LANGUAGE plperl VOLATILE > COST 100; > > > > -- > --------------------------------------- > Viktor Bojovi?? > --------------------------------------- > Wherever I go, Murphy goes with me