Michael Fuhr <[EMAIL PROTECTED]> writes:
> On Mon, Jun 25, 2007 at 12:35:11AM -0400, Tom Lane wrote:
>> Even with no other columns involved, if you're on a machine with
>> MAXALIGN = 8 (which includes all 64-bit platforms as well as some
>> that aren't), the row width won't shrink.
> I see table s
On Monday 25 June 2007 03:35, [EMAIL PROTECTED] wrote:
> 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 d
<[EMAIL PROTECTED]> writes:
> 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 yo
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
<[EMAIL PROTECTED]> writes:
> 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 sto
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
On Mon, Jun 25, 2007 at 12:35:11AM -0400, Tom Lane wrote:
> As for that pg_dump measurement, the text form isn't going to get
> smaller ... "1.2" is the same length as "1.2".
Non-text formats like -Fc should (or might) shrink, right? They
appear to in the tests I've done.
--
Michael Fuhr
-
On Mon, Jun 25, 2007 at 12:35:11AM -0400, Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
> > On Mon, Jun 25, 2007 at 09:51:30AM +0900, [EMAIL PROTECTED] wrote:
> >> It seems that real takes 8 byte storage sizes.
>
> > Real is 4 bytes but other columns' alignment requirements might
> >
Michael Fuhr <[EMAIL PROTECTED]> writes:
> On Mon, Jun 25, 2007 at 09:51:30AM +0900, [EMAIL PROTECTED] wrote:
>> But PostgreSQL's data disk usage did not shrinked.
>> And pg_dump size remained same.
>> It seems that real takes 8 byte storage sizes.
> Real is 4 bytes but other columns' alignment re
On Mon, Jun 25, 2007 at 09:51:30AM +0900, [EMAIL PROTECTED] wrote:
> 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.
Altering a column's type rewrites the table so vacuuming afterward
shouldn't be neces
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:
12 matches
Mail list logo
