W dniu 20.07.2011 17:57, Jose Ildefonso Camargo Tolosa pisze:
[...]
Many of the advantages of partitioning have to do with maintenance
tasks. For example, if you gather data on a daily basis, it's faster
to drop the partition that contains Thursday's data than it is to do a
DELETE that finds the rows and deletes them one at a time. And VACUUM
can be a problem on very large tables as well, because only one VACUUM
can run on a table at any given time. If the frequency with which the
table needs to be vacuumed is less than the time it takes for VACUUM
to complete, then you've got a problem.
And.... pg_largeobject table doesn't get vacuumed? I mean, isn't that
table just as any other table?
Vacuum is a real problem on big pg_largeobject table. I have 1.6 TB
database mostly with large objects and vacuuming that table on fast SAN
takes about 4 hours:
now | start | time | datname |
current_query
---------------------+---------------------+----------+------------+----------------------------------------------
2011-07-20 20:12:03 | 2011-07-20 16:21:20 | 03:50:43 | bigdb |
autovacuum: VACUUM pg_catalog.pg_largeobject
(1 row)
LO generates a lot of dead tuples when object are adding:
relname | n_dead_tup
------------------+------------
pg_largeobject | 246731
Adding LO is very fast when table is vacuumed. But when there is a lot
of dead tuples adding LO is very slow (50-100 times slower) and eats
100% of CPU.
It looks that better way is writing object directly as a bytea on
paritioned tables althought it's a bit slower than LO interface on a
vacuumed table.
Regards,
Andrzej
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
