Re: vacuum, performance, and MVCC

> > Here we have for example some tables which are frequently updated but
> > contain >100 million rows. Vacuuming that takes hours. And the dead row
> > candidates are the ones which are updated again and again and looked up
> > frequently...
>
> This demonstrates that "archival" material and "active" data should be
> kept separately.
>
> They have different access patterns; kludging them into the same table
> turns out badly.

Rightfully it should be up to the database engine to ensure that both of
these patterns work against the same structure. Splitting up the data
for their access patterns is the job of partitions (hidden from the end
user preferably).

Same table good, same partition and possible same table space is bad.

--