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
