Re: Database storage bloat

From: "Tony and Bryn Reina" <reina_ga(at)hotmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Stephan Szabo" <sszabo(at)megazone(dot)bigpanda(dot)com>, <pgsql-admin(at)postgresql(dot)org>
Subject: Re: Database storage bloat
Date: 2004-04-09 05:09:11
Message-ID: BAY8-DAV64SOlbpH71y00020ce6@hotmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

> I don't see orders-of-magnitude bloat here though. You've got 16 bytes
> of useful data per row (which I suppose was 12 bytes in the flat file?).
> There will be 28 bytes of overhead per table row. In addition the index
> will require 12 data bytes + 12 overhead bytes per entry; allowing for
> the fact that b-tree only likes to pack pages about 2/3ds full, we could
> estimate index size as about 36 bytes per original row, giving an
> aggregate bloat factor of 6.67X compared to a binary flat file if the
> flat file needed 12 bytes per row.
>
> The only way I could see to get to a 65X bloat factor would be if you'd
> repeatedly updated the table rows without vacuuming.

Thanks Tom (and everyone else). At least I feel more comfortable that
there's not something obvious. I did perform a 'vacuum full', but still no
dice. At least thanks to Stephan I've narrowed my search down to one table
and I have a ballpark theoretical bloat to shoot for (6 .67X). I'm going to
go back and try to determine if I'm correctly interpretting the part of the
flat file that holds this table's data.

-Tony

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Tom Lane 2004-04-09 05:15:05 Re: Multiple disks
Previous Message Tom Lane 2004-04-09 04:22:53 Re: parameter to control cycle detection