Benoit.Gerrienne@xxxxxxx writes: > At a customer site, we've made a migration from Oracle 8.1.5 to PGSQL > 8.1.1. The migration happened without any problem and now the performances > are better with PG than with Ora, but the customer noticed that the size > of PG on disk where much greater than the size on disk of Oracle. And I'm > not able to find an easy explanation. > > Is it normal, due to inner data storage mecanisms differents between > Oracle and PG ? To a certain degree yes. It's one of the topics under active discussion for improvement in the future. In particular you'll see a big difference if you have a lot of very small columns. You may also see some difference if you have very narrow rows because of the transaction status overhead. > Of course, we've run VACUUM on both DB before measuring the size on disk. There's a couple problems here though. Firstly VACUUM doesn't usually shrink the actual size of data on disk, it just notes where the free space is so it can be reused. To shrink the actual data on disk you would need VACUUM FULL, CLUSTER, or ALTER TABLE ... ALTER COLUMN ... TYPE USING. However under normal operation Postgres expects to have some amount of free space anyways. Running VACUUM FULL is usually pointless and actually hurts performance unless you have an unusual situation such as having done large batch updates recently or not having run VACUUM regularly enough in the past. Because Postgres keeps free space around in the tables for new versions of tuples you should include Oracle's rollback segments in the comparison since that effectively corresponds to the free space Postgres keeps. Or you could do a VACUUM FULL before comparing but I do not recommend VACUUM FULL for regular operation. > The database is used to store statistical data by month and therefore > contain dozen of tables of the same layout containing most of the time > hundred of thousands records. You may find it makes more sense to store this all in one table or in tables that are children of the same table such as described in: http://www.postgresql.org/docs/8.1/static/ddl-partitioning.html -- greg
