>
>> If you suspect your tables or indexes are bloated, restore your=20=
=20
>> dump to a test box.
>> Use fsync=3Doff during restore, you don't care about integrity on
th=
e=20=20
>> test box.
>> This will avoid slowing down your production database.
>> Then look at the size of the restored database.
>> If it is much smaller than your production database, then you have=
=20=20
>> bloat.
>
> I have done that, and I get the following:
>
> the live one is 113G
> the restored one is 78G
Ah.
Good news for you is that you know that you can do something ;)
Now, is the bloat in the tables (which tables ?) or in the indexes
(which=
=20=20
indexes ?), or in the toast tables perhaps, or in the system catalogs
or=20=
=20
all of the above ? Or perhaps there is a long-forgotten process that
got=20=
=20
zombified while holding a huge temp table ? (not very likely, but
who=20=20
knows).
Use pg_relation_size() and its friends to get an idea of the size
of=20=20
stuff.
Perhaps you have 1 extremely bloated table or index, or perhaps=20=20
everything is bloated.
The solution to your problem depends on which case you have.
--=20
Sent via pgsql-performance mailing list (pgsql-performance@[EMAIL PROTECTED]
)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
|
