Search Postgresql Archives

append_array causes rapid growth according to pg_total_relation_size

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

Using Postgres 8.4, I create this table:

rcs_test=> \d array_big1;
    Table "public.array_big1"
  Column   |   Type   | Modifiers 
-----------+----------+-----------
 id        | integer  | not null
 chunk_ids | bigint[] | 
Indexes:
    "array_big1_pkey" PRIMARY KEY, btree (id)

It's initially populated with a single record with chunk_ids having a
1024^2 sized array of big integers.  Immediately after creation, things
look as expected.

rcs_test=> select pg_total_relation_size('array_big1');
 pg_total_relation_size 
------------------------
                8757248
(1 row)

rcs_test=> select pg_column_size(chunk_ids) from array_big1;
 pg_column_size 
----------------
        8388628
(1 row)



Now, after I append the array with a single big integer, the table size
nearly doubles according to pg_total_relation_size, but pg_column_size
looks OK.


rcs_test=> update array_big1 set chunk_ids = array_append(chunk_ids,
'12345678912345') where id = 0;
UPDATE 1

rcs_test=> select pg_total_relation_size('array_big1');
 pg_total_relation_size 
------------------------
               17448960
(1 row)

rcs_test=> select pg_column_size(chunk_ids) from array_big1;
 pg_column_size 
----------------
        8388636
(1 row)


And If I append again:

rcs_test=> select pg_total_relation_size('array_big1');
 pg_total_relation_size 
------------------------
               26255360
(1 row)


A few more and it gets out of hand:

rcs_test=> select pg_total_relation_size('array_big1');
 pg_total_relation_size 
------------------------
              104529920
(1 row)


VACUUM ANALYZE, doesn't seem to help but VACUUM FULL does.  Though
according to the docs, VACUUM FULL is bad.


I'm wondering if this is something that Postgres will take care of on
its own or something that could cause trouble.


If you're wondering why I'm using this approach instead of using another
table, that's probably for another thread, but in short, the overhead of
another table plus indexes is enormous compared to the array, which has
almost no overhead.


-Randall


-- 
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux