Received: from localhost (unknown [200.46.204.183])
	by postgresql.org (Postfix) with ESMTP id 153772E0136
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Fri,  7 Mar 2008 05:29:40 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024)
	with ESMTP id 93441-01 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Fri,  7 Mar 2008 05:29:34 -0400 (AST)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.5
Received: from py-out-1112.google.com (py-out-1112.google.com
 [64.233.166.182])
	by postgresql.org (Postfix) with ESMTP id 394B62E2A35
	for <pgsql-performance@postgresql.org>;
	Fri,  7 Mar 2008 05:29:34 -0400 (AST)
Received: by py-out-1112.google.com with SMTP id d37so807776pye.29
	for <pgsql-performance@postgresql.org>;
	Fri, 07 Mar 2008 01:29:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
	bh=2MF5yQvoZFUTADzWCbOG5QTIjV6+P158nRE6foER3SE=;
	b=Qpv34ZixCWP408HBDPT7iO//KHqQJoISNW7v+eqPdIZokvpDHrgpDGc+1U5/LDCTFgPV6GforPAnBVi5pRhq4lfj441h2VZovUKklFAkEohNm5fEs0aq3QnOWv2mJsJQCKAhreO1U8QJg/CsH4pdL3ZHZTBF5Sss8z7RBCS+hhE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
	b=Qqib7ETpR7sFGF0nn0QIq1Y+UmyRuQ8nBirZFekPmuD2DONJjkf4FF2E/wDhWJv3b0VldSWahU0hbLZbkarrvbhlxYy7FavkdOMEg4ysZ9wyp37ARH4kPc3vjCmGEwRlkwlnptNxgmOghzHdIsxVV8+6TGdkSGWFTWQ12fyvMmo=
Received: by 10.64.179.12 with SMTP id b12mr352527qbf.96.1204882173099;
	Fri, 07 Mar 2008 01:29:33 -0800 (PST)
Received: by 10.64.3.7 with HTTP; Fri, 7 Mar 2008 01:29:33 -0800 (PST)
Message-ID: <3556c08c0803070129y6ffabf32i1c8bae445ec460e0@mail.gmail.com>
Date: Fri, 7 Mar 2008 10:29:33 +0100
From: "Pavel Rotek" <pavel.rotek@gmail.com>
To: pgsql-performance@postgresql.org
Subject: Re: Toast space grows
In-Reply-To: <47D10722.4080508@archonet.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_25097_9533226.1204882173100"
References: <3556c08c0803070035p6d8b4aa8m6318f54728f61022@mail.gmail.com>
	<47D10722.4080508@archonet.com>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0.001 tagged_above=0 required=5
	tests=HTML_MESSAGE=0.001
X-Spam-Level: 
X-Archive-Number: 200803/152
X-Sequence-Number: 29106

------=_Part_25097_9533226.1204882173100
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

we just restored it to free 70G :-(

There are inserts and few updates (but what do you mean with update??
committed update??, because there are many updates of the log attribute in
trasaction, we do periodical flush during transaction), sum takes
approximately 1,2G, and i mean vacuum full (but there is no lock on the
table when running vacuum full). I haven't try plain vacuum.

2008/3/7, Richard Huxton <dev@archonet.com>:
>
> Pavel Rotek wrote:
> > Hello,
> >
> > i have problem with following table...
> >
> > create table dataaction (
> >    id INT4 not null,
> >    log text,
> >    primary key (id)
> > );
> >
> > It is the table for storing results of long running jobs. The log
> attribute
> > takes approximately 5MB for one row (there is about 300 rows). My
> problem
> > is, that table dataaction takes after restoring about 1,5G, but in few
> days
> > grows to 79G(Toast space)...
>
>
> 1. What is happening with this table - just inserts, lots of updates?
>
> 2. What does SELECT sum(length(log)) FROM dataaction; show?
>
>
>   > Vacuum on the table doesn't finish.
>
>
> A plain vacuum doesn't finish, or vacuum full doesn't finish?
>
>
> --
>    Richard Huxton
>    Archonet Ltd
>

------=_Part_25097_9533226.1204882173100
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

we just restored it to free 70G :-(<br><br>There are inserts and few updates (but what do you mean with update?? committed update??, because there are many updates of the log attribute in trasaction, we do periodical flush during transaction), sum takes approximately 1,2G, and i mean vacuum full (but there is no lock on the table when running vacuum full). I haven&#39;t try plain vacuum.<br>
<br><div><span class="gmail_quote">2008/3/7, Richard Huxton &lt;<a href="mailto:dev@archonet.com">dev@archonet.com</a>&gt;:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Pavel Rotek wrote:<br> &gt; Hello,<br> &gt;<br> &gt; i have problem with following table...<br> &gt;<br> &gt; create table dataaction (<br> &gt;&nbsp;&nbsp;&nbsp;&nbsp;id INT4 not null,<br> &gt;&nbsp;&nbsp;&nbsp;&nbsp;log text,<br> &gt;&nbsp;&nbsp;&nbsp;&nbsp;primary key (id)<br> &gt; );<br>
 &gt;<br> &gt; It is the table for storing results of long running jobs. The log attribute<br> &gt; takes approximately 5MB for one row (there is about 300 rows). My problem<br> &gt; is, that table dataaction takes after restoring about 1,5G, but in few days<br>
 &gt; grows to 79G(Toast space)...<br> <br> <br>1. What is happening with this table - just inserts, lots of updates?<br> <br> 2. What does SELECT sum(length(log)) FROM dataaction; show?<br> <br><br>&nbsp;&nbsp;&gt; Vacuum on the table doesn&#39;t finish.<br>
 <br> <br>A plain vacuum doesn&#39;t finish, or vacuum full doesn&#39;t finish?<br> <br><br> --<br>&nbsp;&nbsp; Richard Huxton<br>&nbsp;&nbsp; Archonet Ltd<br> </blockquote></div><br>

------=_Part_25097_9533226.1204882173100--