Обсуждение: Disk space usage

Поиск
Список
Период
Сортировка

Disk space usage

От
"Joe Bloggs"
Дата:
I created a table in 8.1.5 on Linux with three columns;

date, bigint and integer.

Then I populated the table with more than 2 million rows.

I looked at the size of the file that contained the table and divided this by the number of rows which gave an average of just over 60 bytes per row.

This seems to be quite a large overhead as I would guess that the date field takes around 4 bytes, the bigint 8 bytes and the integer 4 bytes. I would have hoped to have had an average size of between 20 and 30 bytes per row. Is this normal and is there any way of improving this as I'm hoping to use have around 80 million rows in a table without it taking up too much disk space and too much memory to cache it?

Regards

Joe

Re: Disk space usage

От
Scott Marlowe
Дата:
On Wed, 2006-11-29 at 13:57, Joe Bloggs wrote:
> I created a table in 8.1.5 on Linux with three columns;
>
> date, bigint and integer.
>
> Then I populated the table with more than 2 million rows.
>
> I looked at the size of the file that contained the table and divided
> this by the number of rows which gave an average of just over 60 bytes
> per row.
>
> This seems to be quite a large overhead as I would guess that the date
> field takes around 4 bytes, the bigint 8 bytes and the integer 4
> bytes. I would have hoped to have had an average size of between 20
> and 30 bytes per row. Is this normal and is there any way of improving
> this as I'm hoping to use have around 80 million rows in a table
> without it taking up too much disk space and too much memory to cache
> it?

Had you done any updates to the tables?  If so, had you run a vacuum
full?

Re: Disk space usage

От
Tom Lane
Дата:
Scott Marlowe <smarlowe@g2switchworks.com> writes:
> On Wed, 2006-11-29 at 13:57, Joe Bloggs wrote:
>> I created a table in 8.1.5 on Linux with three columns;
>> date, bigint and integer.
>>
>> I looked at the size of the file that contained the table and divided
>> this by the number of rows which gave an average of just over 60 bytes
>> per row.
>>
>> This seems to be quite a large overhead as I would guess that the date
>> field takes around 4 bytes, the bigint 8 bytes and the integer 4
>> bytes. I would have hoped to have had an average size of between 20
>> and 30 bytes per row.

> Had you done any updates to the tables?

I think it's about dead on, if he's using a machine with MAXALIGN 8:

    Row's item pointer    4 bytes
    Row header        32 bytes (including alignment padding)
    date column        4 bytes
    alignment padding    4 bytes
    bigint column        8 bytes
    integer column        4 bytes
    alignment padding    4 bytes
                --------
                60 bytes

The choice of column order is unfortunate --- if he'd put the bigint
column either first or last, there wouldn't be the alignment penalties.

Hopefully we'll be able to get the row header back down to 24 bytes in
8.3, but it's never going to be the 4-or-so-bytes that the OP is
imagining.

            regards, tom lane