Dimensioni delle tabelle e dei dati dump di testo, qualche insignificante esperimento

Mi sono ritrovato per le mani una vecchia e obsoleta istanza PostgreSQL 8.4 piuttosto grossa, lo spazio disco del tablespace
risultava essere di circa 13 GB! Ho quindi preso spunto per fare una piccola indagine su cosa occupasse tanto spazio,
concentrandomi solo sulle relazioni (tabelle):

SELECT c.oid,nspname AS table_schema
      , relname AS TABLE_NAME
      , c.reltuples AS row_estimate
      , to_char( pg_total_relation_size(c.oid)::real/(1024*1024), '99G999D99' ) AS MB
FROM pg_class c LEFT JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE
      relkind = 'r'
      AND
      nspname = 'public'
ORDER BY 4 DESC, 3 ASC;

Ebbene sono saltate subito all'occhio tre tabelle in particolari (nomi di fantasia):

  oid   | table_schema | table_name | row_estimate |     mb
---------+--------------+------------+--------------+------------
   63740 | public       | tab1      |  8.74153e+06 |   2.248,58
   66161 | public       | tab2      |   2.9728e+06 |   1.192,00
   65032 | public       | tab3      |  2.44735e+06 |   1.280,77

Come si nota queste tre tabelle superano di slancio ciascuna una occupazione di 1 GB, arrivando fino a 9 milioni di tuple circa!
Insomma, non una cosa eccezionale per PostgreSQL, ma sicuramente nemmeno una cosa di routine, e che comunque indica forse la necessità
di una riprogettazione o di un partitioning.
Comunque, le stesse tabelle su disco quando occuperebbero in formato testo?

% pg_dump -h localhost -U luca -t tab1 testdb > tab1.sql

Effettuando il dump, con molta pazienza, di quelle tre tabelle sopra indicate si ottiene che:

% ls -lh tab?.sql
-rw-r--r-- 1 luca luca 579M 2017-04-12 11:32 tab1.sql
-rw-r--r-- 1 luca luca 494M 2017-04-12 11:37 tab2.sql
-rw-r--r-- 1 luca luca 571M 2017-04-12 11:36 tab3.sql

e quindi lo spazio occupato all'interno di PostgreSQL risulta da 2 a 4 volte superiore allo spazio disco dei dati testuali.
Chiaramente questa non rappresenta una inefficienza di PostgreSQL, quanto una naturale esigenza del database di tenere i dati allineati,
avere le pagine dati (8kB) con spazio sufficiente per consentire aggiornamenti, ecc.


Se si effettua un vacuum full sulle tabelle di cui sopra si ottiene il seguente risultato:

> vacuum full verbose tab1;
...
0 index pages have been deleted, 0 are currently reusable.

ad indicare che il database era già "buono", e abbastanza compattato. Ovviamente i dati che PostgreSQL riporta sul numero di tuple e dimensione
dei dati sono rimaste invariate.