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

Поиск
Список
Период
Сортировка
От Adrian Klaver
Тема Re: database is bigger after dump/restore - why? (60 GB to 109 GB)
Дата
Msg-id 201103040753.24671.adrian.klaver@gmail.com
обсуждение исходный текст
Ответ на Re: database is bigger after dump/restore - why? (60 GB to 109 GB)  (Aleksey Tsalolikhin <atsaloli.tech@gmail.com>)
Ответы Re: database is bigger after dump/restore - why? (60 GB to 109 GB)  (Aleksey Tsalolikhin <atsaloli.tech@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Thufir Hawat
Дата:
Сообщение: script errors or PEBKAC?
Следующее
От: Michael Black
Дата:
Сообщение: Re: script errors or PEBKAC?