Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id 94C4D111581 for ; Tue, 14 Feb 2012 09:22:48 -0400 (AST) Received: from extern.innogames.de ([80.252.99.240]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1RxILF-0005vr-U2 for pgsql-admin@postgresql.org; Tue, 14 Feb 2012 13:22:47 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by extern.innogames.de (Postfix) with ESMTP id 14AFA5E8004 for ; Tue, 14 Feb 2012 14:22:33 +0100 (CET) Received: from extern.innogames.de ([127.0.0.1]) by localhost (extern.innogames.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwnnBKdnDahq for ; Tue, 14 Feb 2012 14:22:33 +0100 (CET) Received: from [172.16.5.29] (unknown [212.48.107.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extern.innogames.de (Postfix) with ESMTPSA id EB87A5E8002 for ; Tue, 14 Feb 2012 14:22:32 +0100 (CET) Message-ID: <4F3A6018.3000902@innogames.de> Date: Tue, 14 Feb 2012 14:22:32 +0100 From: Bernhard Schrader User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: pgsql-admin@postgresql.org Subject: Big difference in databasesize compared with disksize Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201202/57 X-Sequence-Number: 39117 Hi all, Problem: If I use SELECT pg_size_pretty(pg_database_size('dbname')) As fulldbsize; fulldbsize ------------ 6455 MB (1 row) If I compare this output with /var/lib/postgresql/9.0/main/base/[DBFOLDER] I have a difference of 3 GB, which I think is not normal. To make a little bit clearer what i mean: /var/lib/postgresql/9.0/main/base/43169# du --apparent-size -h 6.4G . /var/lib/postgresql/9.0/main/base/43169# du -sh 9.4G . Is such a big fragmentation a normal behavior? It's splitted to several Filenodes. I also made a "xfs_fsr" to defrag all of this, i gathered around 1 GB back ( would be more if the tables wouldn't be written in this time ) But within some hours the fragmentation was back.. There is also no big dead tuple count in this database, it's getting a vacuum analyze every night. Right now i am out of ideas... What do you think i could do? If you need more information i can provide. Environment: - OS: Debian Lenny - Disksize: 15GB - Filesystem: XFS - Psql: 9.0.3 thanks in advance. regards Bernhard