Hidata compression is relatively erratic in my experience.  It does
compress row by row, so the results you got in your tests is probably
an accident.  It's been a while since I used hidata, but I think it
tends to work best on relatively wide rows;  short rows may not
compress very well.  (and hidata is definitely a CPU hog.)

Yes, if you uncompress any compressed table it can get bigger, and you
could hit the page limit if the uncompressed table is large.

Karl

André,
We needed to reduce the size of one of our production DB's
which was outgrowing its server; we experimented with various table
compression options in Ingres II
but in the end we simply modified 5 of our big BTREE tables to ISAM,
which yielded a big (~25%) per table space saving.
Not sexy, but this solution was simple, had no reoprted performance
hit,
avoided any concerns with compression and had good knock-on effects for
our batch
work and checkpoint speed.
HTH Steve

André,
We needed to reduce the size of one of our production DB's
which was outgrowing its server; we experimented with various table
compression options in Ingres II
but in the end we simply modified 5 of our big BTREE tables to ISAM,
which yielded a big (~25%) per table space saving.
Not sexy, but this solution was simple, had no reoprted performance
hit,
avoided any concerns with compression and had good knock-on effects for
our batch
work and checkpoint speed.
HTH Steve