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

From: Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com>
To: pgsql-general(at)postgresql(dot)org
Cc: Aleksey Tsalolikhin <atsaloli(dot)tech(at)gmail(dot)com>
Subject: Re: database is bigger after dump/restore - why? (60 GB to 109 GB)
Date: 2011-03-04 15:53:24
Message-ID: 201103040753.24671.adrian.klaver@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Adrian Klaver <adrian(dot)klaver(at)gmail(dot)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(dot)klaver(at)gmail(dot)com

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Michael Black 2011-03-04 18:41:30 Re: script errors or PEBKAC?
Previous Message Thufir Hawat 2011-03-04 15:48:04 script errors or PEBKAC?