David Wall <[EMAIL PROTECTED]> writes:
> Does the psql command 'vacuum;' by itself automatically vacuum
> pg_largeobject along with all of tables in the database?
Yes, if it's issued by a superuser or the database owner.
However, that won't help much if pg_largeobject has become bloated by a
lo
If there are no other tables storing large objects in the database,
dropping and reloading the whole database is probably the simplest
solution. Otherwise they're going to need to make sure the unwanted
LOs have been cleaned out (see contrib/vacuumlo) and then do a VACUUM
FULL or similar on pg_
Hi ,
Before you do any thing like upgrade backup is the mantra
- in plain sql format
- File system base ( remember to shutdown postgresql before taking
backup)
- pg_dump
Queries :-
>
> 1) Can we do rollback if required after complete installation??
>
Yes you would be able to,
Kevin Kempter <[EMAIL PROTECTED]> writes:
> 3) we did a pg_dump and a reload into a database on the test box and the
> table
> is still 30Gig.
You need to find out *exactly* what they did there.
The idea that comes to mind is that they dropped and reloaded the table
itself, but didn't do anythi
Kevin Kempter написа:
Hi List;
I'm engaging with a client who is trying to solve what sounds like a bloat
issue. However in further conversations they told me this:
1) we have a table that is an integer key and a blob column
2) the table was at 30Gig, we went in and deleted the last 2 months
Hi List;
I'm engaging with a client who is trying to solve what sounds like a bloat
issue. However in further conversations they told me this:
1) we have a table that is an integer key and a blob column
2) the table was at 30Gig, we went in and deleted the last 2 months of data
and it's still a
