Re: Deleting bytea, autovacuum, and 8.2/8.4 differences

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: VJK <vjkmail(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Deleting bytea, autovacuum, and 8.2/8.4 differences
Date: 2010-03-15 14:53:22
Message-ID: 17919.1268664802@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Greg Smith <greg(at)2ndquadrant(dot)com> writes:
> VJK wrote:
>> Since Pg does not use the concept of rollback segments, it is unclear
>> why deletion produces so much disk IO (4GB).

> With PostgreSQL's write-ahead log, MVCC and related commit log, and
> transactional DDL features, there's actually even more overhead that can
> be involved than a simple rollback segment design when you delete things:

For an example like this one, you have to keep in mind that the
toast-table rows for the large bytea value have to be marked deleted,
too. Also, since I/O happens in units of pages, the I/O volume to
delete a tuple is just as much as the I/O to create it. (The WAL
entry for deletion might be smaller, but that's all.) So it is entirely
unsurprising that "DELETE FROM foo" is about as expensive as filling the
table initially.

If deleting a whole table is significant for you performance-wise,
you might look into using TRUNCATE instead.

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Matthew Wakeling 2010-03-15 15:18:07 Re: Deleting bytea, autovacuum, and 8.2/8.4 differences
Previous Message VJK 2010-03-15 14:46:05 Re: Deleting bytea, autovacuum, and 8.2/8.4 differences