On Thu, Jun 16, 2005 at 04:20:34PM +1000, Gavin Sherry wrote:
> 2) By no fault of its own, autovacuum's level of granularity is the table
> level. For people dealing with non-trivial amounts of data (and we're not
> talking gigabytes or terabytes here), this is a serious drawback. Vacuum
> at peak times can cause very intense IO bursts -- even with the
> enhancements in 8.0. I don't think the solution to the problem is to give
> users the impression that it is solved and then vacuum their tables during
> peak periods. I cannot stress this enough.
People running systems with petabyte-sized tables can disable autovacuum
for those tables, and leave it running for the rest. Then they can
schedule whatever maintenance they see fit on their gigantic tables.
Trying to run a database with more than a dozen gigabytes of data
without expert advice (or at least reading the manual) would be
extremely stupid anyway.
--
Alvaro Herrera (<alvherre[a]surnet.cl>)
"¿Cómo puedes confiar en algo que pagas y que no ves,
y no confiar en algo que te dan y te lo muestran?" (Germán Poo)
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
