On Sat, Feb 13, 2010 at 12:19 AM, Greg Smith wrote:
> Amitabh Kant wrote:
>>
>> You need to do VACUUM FULL ANALYZE to claim the disk space, but this
>> creates a exclusive lock on the tables.
>> See http://www.postgresql.org/docs/8.3/static/sql-vacuum.html
>
> First off, you don't need the ANALYZE
Marcin Krol wrote:
Result before (1.6G db):
size_in_bytes | relname
---+--
806387712 | cs_ver_digests_pkey
103530496 | oai_edi_atts_pkey
There's your problem. This is called "index bloat"; these are the two
biggest relations in the large and
Amitabh Kant wrote:
You need to do VACUUM FULL ANALYZE to claim the disk space, but this
creates a exclusive lock on the tables.
See http://www.postgresql.org/docs/8.3/static/sql-vacuum.html
First off, you don't need the ANALYZE in there.
Second, VACUUM FULL is a terrible way to fix a table t
Bill Moran wrote:
Note that the "correct" disk size for your database is probably closer
to the 1.6G you were seeing before.
This might be the case, but how do I find out what are the "correct" sizes?
I have a script that does following queries:
SELECT relpages * 8192 AS size_in_bytes, reln
In response to Marcin Krol :
> Amitabh Kant wrote:
> > You need to do VACUUM FULL ANALYZE to claim the disk space, but this
> > creates a exclusive lock on the tables.
> >
> > See http://www.postgresql.org/docs/8.3/static/sql-vacuum.html
>
> Aha!
>
> OK but why did the performance degrade so m
On Fri, 2010-02-12 at 18:43 +0100, Marcin Krol wrote:
> Amitabh Kant wrote:
> > You need to do VACUUM FULL ANALYZE to claim the disk space, but this
> > creates a exclusive lock on the tables.
> >
> > See http://www.postgresql.org/docs/8.3/static/sql-vacuum.html
>
> Aha!
>
> OK but why did the
Amitabh Kant wrote:
You need to do VACUUM FULL ANALYZE to claim the disk space, but this
creates a exclusive lock on the tables.
See http://www.postgresql.org/docs/8.3/static/sql-vacuum.html
Aha!
OK but why did the performance degrade so much? The same reason -- lack
of autovacuuming/vacuum
On Fri, Feb 12, 2010 at 10:40 PM, Marcin Krol wrote:
> Hello,
>
> The db in the application I maintain but didn't write (it obviously
> makes use of PG, v 8.3), has been systematically growing in size from
> about 600M to 1.6G.
>
> At the same time, the performance of the app has degraded signifi
Hello,
The db in the application I maintain but didn't write (it obviously
makes use of PG, v 8.3), has been systematically growing in size from
about 600M to 1.6G.
At the same time, the performance of the app has degraded significantly
(several times).
So I've done VACUUM ANALYZE on entire db.
