Re: database is bigger after dump/restore - why? (60 GB to 109 GB) - Mailing list pgsql-general

From Adrian Klaver
Subject Re: database is bigger after dump/restore - why? (60 GB to 109 GB)
Date
Msg-id 201103040753.24671.adrian.klaver@gmail.com
Whole thread Raw
In response to Re: database is bigger after dump/restore - why? (60 GB to 109 GB)  (Aleksey Tsalolikhin <atsaloli.tech@gmail.com>)
Responses Re: database is bigger after dump/restore - why? (60 GB to 109 GB)  (Aleksey Tsalolikhin <atsaloli.tech@gmail.com>)
List pgsql-general
On Thursday, March 03, 2011 6:15:50 pm Aleksey Tsalolikhin wrote:
> On Tue, Mar 1, 2011 at 7:24 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Adrian Klaver <adrian.klaver@gmail.com> writes:
> >> Looks like the TOAST compression is not working on the second machine.
> >> Not sure how that could come to be. Further investigation underway:)
> >
> > Somebody carelessly messed with the per-column SET STORAGE settings,
> > perhaps?  Compare pg_attribute.attstorage settings ...
>
> Thank you.  I compared the STORAGE settings and I have "extended" on
> both databases,
> no "external".
>
> Any other ideas?

Weird. The pgstattuple data shows that the tables are essentially the same, the
only difference being the dead tuples, as expected, on the production table. The
TOAST size information shows approximately a doubling in size of the TOASTed
data on the new machine. By all accounts compression or the lack thereof would
be the culprit. At this point I am at a loss for another explanation.

One more request for information. What is the data being stored in the table?

>
> Yours truly,
> -at

--
Adrian Klaver
adrian.klaver@gmail.com

pgsql-general by date:

Previous
From: Thufir Hawat
Date:
Subject: script errors or PEBKAC?
Next
From: Michael Black
Date:
Subject: Re: script errors or PEBKAC?