Gregory Stark <[EMAIL PROTECTED]> wrote:
This could also be due to alignment restrictions on the other columns or the
row as a whole. If you're curious exactly what's going on and how to optimize
your table layout send your table definition and we can tell you exactly how
it's being laid out and
Michael Fuhr <[EMAIL PROTECTED]> wrote:
Altering a column's type rewrites the table so vacuuming afterward
shouldn't be necessary.
I'm gonna alter another table type from double precision to real.
This table size is lager than disk free space.
Can it be possible?
Previsouly, I saw continuous in
Actually, table size shrinked a little.
But I misinterpreted it as no shrinking.
I expected much more shrinking.
Thank you for your concerns.
Michael Fuhr <[EMAIL PROTECTED]> wrote:
I see table sizes shrink on 64-bit sparc and x86 architectures, as
in the following example that results in adjac
Real type takes 4 byte storage sizes and double precision takes 8 bytes.
I altered a data type from double precision to real and vacuumed DB.
But PostgreSQL's data disk usage did not shrinked.
And pg_dump size remained same.
It seems that real takes 8 byte storage sizes.
Here's my environments:
