Re: newbie design question re impact of VACUUM

In article <1131466149(dot)590544(dot)159870(at)g43g2000cwa(dot)googlegroups(dot)com>,
"shakahshakah(at)gmail(dot)com" <shakahshakah(at)gmail(dot)com> writes:

> As a background, I'll be using Postgres in part as a processing queue
> for a 40-column stream of information (~ 250 bytes/row) with a
> sustained input rate of 20 rows/sec. This queue will be processed
> periodically (every few minutes), design constraints are to (1) only
> process each row once, and (2) keep the processed rows around for a
> period of time (say a month or so).

> My first (naive?) idea was to add a boolean "was_processed" column to
> the table (defaulted to false) and UPDATE it to true as part of (1).
> After reading Chapter 22, though, it seems that even a minor UPDATE
> like that copies the row and requires VACUUMing.

That's true, but there might be a way to avoid it. If your queue
elements have a timestamp, you could run your processing routine not
over elements where "was_processed" is false, but over elements within
some time interval, e.g. the last minute. This would eliminate the
need for an UPDATE.