From: | Dmitriy Igrishin <dmitigr(at)gmail(dot)com> |
---|---|
To: | Tamas Vincze <vincze(at)neb(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: TRUNCATE pg_largeobject |
Date: | 2011-07-25 21:11:19 |
Message-ID: | CAAfz9KNtL=JKjQ_zThk52iQT5NTwQtC6NpGydZYOS2u-2N+UMw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hey Tamas,
2011/7/25 Tamas Vincze <vincze(at)neb(dot)com>
> Is it safe?
>
> This table is around 500GB and because of performance reasons
> I slowly moved all large objects to regular files on a NetApp
> share.
>
> Now it shows 0 records:
>
> # select count(*) from pg_largeobject;
> count
> -------
> 0
> (1 row)
>
> but disk space and RAM by the free space map is still occupied.
> I'd like to clean it up.
> A VACUUM FULL would probably do it, but it would take several
> hours with heavy I/O and I'd like to avoid that on a production
> server.
>
> Can I safely issue a "TRUNCATE pg_largeobject"?
> It is v8.1.9.
>
> Thanks!
>
I think that SELECT lo_unlink(loid) FROM (SELECT DISTINCT loid FROM
pg_largeobject) AS foo
would be better than direct truncation.
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/**mailpref/pgsql-general<http://www.postgresql.org/mailpref/pgsql-general>
>
--
// Dmitriy.
From | Date | Subject | |
---|---|---|---|
Next Message | Tamas Vincze | 2011-07-25 21:17:12 | Re: TRUNCATE pg_largeobject |
Previous Message | Merlin Moncure | 2011-07-25 20:58:13 | Re: pgsql error |