Re: Large files in main/base

From: "Neuber, Dirk" <dirk(dot)neuber(at)barco(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Guillaume Lelarge" <guillaume(at)lelarge(dot)info>
Cc: "Henry, Frank" <frank(dot)henry(at)barco(dot)com>, <pgsql-admin(at)postgresql(dot)org>, "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>
Subject: Re: Large files in main/base
Date: 2010-07-11 12:58:14
Message-ID: ED2EA636E2C9744A96B417491D4793BB07E00D7A@KUUMEX03.barco.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

> >> It is : postgres/8.3/main/base/16385/2613
>
> > This is a system catalog, pg_largeobject, which holds
> binary objects. If
> > you use Large Objects, no wonder this table could be really big.
>
> Also worth noting is that there's no automatic deletion mechanism for
> large objects. It could be that the space is being eaten by LOs that
> aren't referenced anymore. If so, you should think about applying
> contrib/lo and/or contrib/vacuumlo to manage your LOs.
>

Thanks a lot.
vacuumlo did the job. Indeed there were more the 100.000 orphaned LOs in
pg_largeobject.
We have to check how we can avoid this by using contrib/lo or in general
without using LOs.
One last question. After using vacuumlo the file size of 16385/2613 is
still the same as before.
It seems the content has been removed but the file itself hasn't been
compacted.
Is there an option or tool which can do this as well ?

Ciao Dirk.

DISCLAIMER:
Unless indicated otherwise, the information contained in this message is privileged and confidential, and is intended only for the use of the addressee(s) named above and others who have been specifically authorized to receive it. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message and/or attachments is strictly prohibited. The company accepts no liability for any damage caused by any virus transmitted by this email. Furthermore, the company does not warrant a proper and complete transmission of this information, nor does it accept liability for any delays. If you have received this message in error, please contact the sender and delete the message. Thank you.

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Tom Lane 2010-07-11 15:51:00 Re: Large files in main/base
Previous Message Tom Lane 2010-07-10 14:54:46 Re: Large files in main/base