Re: Postgres vs. DSpam

From: Neil Conway <neilc(at)samurai(dot)com>
To: Andrew McMillan <andrew(at)catalyst(dot)net(dot)nz>
Cc: Evilio del Rio <edelrio(at)cmima(dot)csic(dot)es>, dspam-users(at)networkdweebs(dot)com, pgsql-performance(at)postgresql(dot)org
Subject: Re: Postgres vs. DSpam
Date: 2004-11-26 03:25:25
Message-ID: 1101439525.12697.11.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Fri, 2004-11-26 at 14:37 +1300, Andrew McMillan wrote:
> In PostgreSQL the UPDATE will result
> internally in a new record being written, with the old record being
> marked as deleted. That old record won't be re-used until after a
> VACUUM has run, and this means that the on-disk tables will have a lot
> of dead rows in them quite quickly.

Not necessarily: yes, you need a VACUUM to begin reusing the space
consumed by expired tuples, but that does not mean "tables will have a
lot of dead rows in them quite quickly". VACUUM does not block
concurrent database activity, so you can run it as frequently as you'd
like (and as your database workload requires). There is a tradeoff
between the space consumed by expired tuple versions and the I/O
required to do a VACUUM -- it's up to the PG admin to decide what the
right balance for their database is (pg_autovacuum et al. can help make
this decision).

> The reason that PostgreSQL operates this way, is a direct result of the
> way transactional support is implemented, and it may well change in a
> version or two.

I doubt it.

-Neil

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Jerome Macaranas 2004-11-26 08:28:31 Re: [PERFORM] HELP speed up my Postgres
Previous Message Andrew McMillan 2004-11-26 01:37:12 Re: Postgres vs. DSpam