Re: vacuum, performance, and MVCC

Mark Woodward wrote:

> > In case of the number of actively modified rows being in only tens or
> > low hundreds of thousands of rows, (i.e. the modified set fits in
> > memory) the continuous vacuum process shows up as just another backend,
> > not really taking order of magnitude more resources. It mainly generates
> > WAL traffic, as modified pages are already in memory/cache and are
> > mostly synced by background writer and/or checkpoint.
> >
> > Of course you have to adjust vacuum_cost_* variables so as to not
> > saturate IO.
> 
> These sort of solutions, IMHO, don't show how good PostgreSQL is, but show
> where it is very lacking.

We all know Postgres is lacking; some of us try to improve it (some with
more success than others).  People who know the current limitations but
like the capabilities, try to find workarounds to the problems. What
surprises me is that, if you have such a low opinion of Postgres, you
still use it.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.